alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2019-07-12T14:59:58Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4439[v2.7] kernel: udp - fix behavior of wrong checksums (CVE-2015-5364)2019-07-12T14:59:58ZAlexander Belous[v2.7] kernel: udp - fix behavior of wrong checksums (CVE-2015-5364)udp: fix behavior of wrong checksums>
>\[ Upstream commit beb39db59d14990e401e235faf66a6b9b31240b0 \]
>
>We have two problems in UDP stack related to bogus checksums :
>
>1) We return -EAGAIN to application even if receive queu...udp: fix behavior of wrong checksums>
>\[ Upstream commit beb39db59d14990e401e235faf66a6b9b31240b0 \]
>
>We have two problems in UDP stack related to bogus checksums :
>
>1) We return -EAGAIN to application even if receive queue is not
empty.
>This breaks applications using edge trigger epoll()
>
>2) Under UDP flood, we can loop forever without yielding to other
>processes, potentially hanging the host, especially on non SMP.
>
>This patch is an attempt to make things better.
>
>We might in the future add extra support for rt applications
>wanting to better control time spent doing a recv() in a hostile
>environment. For example we could validate checksums before
queuing
>packets in socket receive queue.
**Linux 3.10**
>commit a3cfde2a311c3679b414b46e29d1a184edf29b0a
**Linux 3.14**
>commit 542744f265e23eca08f14a8748a3cbf5feb56cdf
**Linux 3.18**
>commit ee4ab7d8328b0a505d376b6c08d569778c8689af
Reference:
>https://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.10.81
>https://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.14.45
>https://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.18.17
*(from redmine: issue id 4439, created on 2015-07-10, closed on 2017-09-05)*
* Relations:
* parent #4438Alpine 2.7.10Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4437[v3.1] django: Denial-of-service possibility by filling session store (CVE-20...2019-07-23T13:50:40ZAlexander Belous[v3.1] django: Denial-of-service possibility by filling session store (CVE-2015-5143, CVE-2015-5144, CVE-2015-5145)Denial-of-service possibility by filling session store (CVE-2015-5143)
>In previous versions of Django, the session backends created a new
empty record in the session storage anytime request.session was accessed
and there was a session ...Denial-of-service possibility by filling session store (CVE-2015-5143)
>In previous versions of Django, the session backends created a new
empty record in the session storage anytime request.session was accessed
and there was a session key provided in the request cookies that didn’t
already have a session record. This could allow an attacker to easily
create many new session records simply by sending repeated requests with
unknown session keys, potentially filling up the session store or
causing other users’ session records to be evicted.
>
>The built-in session backends now create a session record only if
the session is actually modified; empty session records are not created.
Thus this potential DoS is now only possible if the site chooses to
expose a session-modifying view to anonymous users.
>
>As each built-in session backend was fixed separately (rather than
a fix in the core sessions framework), maintainers of third-party
session backends should check whether the same vulnerability is present
in their backend and correct it if so.
Header injection possibility since validators accept newlines in input
(CVE-2015-5144)
>Some of Django’s built-in validators
(django.core.validators.EmailValidator, most seriously) didn’t prohibit
newline characters (due to the usage of $ instead of \\Z in the regular
expressions). If you use values with newlines in HTTP response or email
headers, you can suffer from header injection attacks. Django itself
isn’t vulnerable because django.http.HttpResponse and the mail sending
utilities in django.core.mail prohibit newlines in HTTP and SMTP
headers, respectively. While the validators have been fixed in Django,
if you’re creating HTTP responses or email messages in other ways, it’s
a good idea to ensure that those methods prohibit newlines as well. You
might also want to validate that any existing data in your application
doesn’t contain unexpected newlines.
>
>django.core.validators.validate\_ipv4\_address(),
django.core.validators.validate\_slug(), and
django.core.validators.URLValidator are also affected, however, as of
Django 1.6 the GenericIPAddresseField, IPAddressField, SlugField, and
URLField form fields which use these validators all strip the input, so
the possibility of newlines entering your data only exists if you are
using these validators outside of the form fields.
>
>The undocumented, internally unused validate\_integer() function is
now stricter as it validates using a regular expression instead of
simply casting the value using int() and checking if an exception was
raised.
Denial-of-service possibility in URL validation (CVE-2015-5145)
>django.core.validators.URLValidator included a regular expression
that was extremely slow to evaluate against certain inputs. This regular
expression has been simplified and optimized.
Affected supported versions
•Django master development branch
•Django 1.8
•Django 1.7 (except the URL DoS issue)
•Django 1.4 (except the URL DoS issue)
Per our supported versions policy, **Django 1.5** and 1.6 are no longer
receiving security updates.
Reference:
https://www.djangoproject.com/weblog/2015/jul/08/security-releases/
*(from redmine: issue id 4437, created on 2015-07-10, closed on 2015-07-31)*
* Relations:
* parent #44353.1.5Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4436[v3.2] django: Denial-of-service possibility by filling session store (CVE-20...2019-07-23T13:50:41ZAlexander Belous[v3.2] django: Denial-of-service possibility by filling session store (CVE-2015-5143, CVE-2015-5144, CVE-2015-5145)Denial-of-service possibility by filling session store (CVE-2015-5143)
In previous versions of Django, the session backends created a new empty
record in the session storage anytime request.session was accessed and
there was a session k...Denial-of-service possibility by filling session store (CVE-2015-5143)
In previous versions of Django, the session backends created a new empty
record in the session storage anytime request.session was accessed and
there was a session key provided in the request cookies that didn’t
already have a session record. This could allow an attacker to easily
create many new session records simply by sending repeated requests with
unknown session keys, potentially filling up the session store or
causing other users’ session records to be evicted.
The built-in session backends now create a session record only if the
session is actually modified; empty session records are not created.
Thus this potential DoS is now only possible if the site chooses to
expose a session-modifying view to anonymous users.
As each built-in session backend was fixed separately (rather than a fix
in the core sessions framework), maintainers of third-party session
backends should check whether the same vulnerability is present in their
backend and correct it if so.
Header injection possibility since validators accept newlines in input
(CVE-2015-5144)
Some of Django’s built-in validators
(django.core.validators.EmailValidator, most seriously) didn’t prohibit
newline characters (due to the usage of $ instead of \\Z in the regular
expressions). If you use values with newlines in HTTP response or email
headers, you can suffer from header injection attacks. Django itself
isn’t vulnerable because django.http.HttpResponse and the mail sending
utilities in django.core.mail prohibit newlines in HTTP and SMTP
headers, respectively. While the validators have been fixed in Django,
if you’re creating HTTP responses or email messages in other ways, it’s
a good idea to ensure that those methods prohibit newlines as well. You
might also want to validate that any existing data in your application
doesn’t contain unexpected newlines.
django.core.validators.validate\_ipv4\_address(),
django.core.validators.validate\_slug(), and
django.core.validators.URLValidator are also affected, however, as of
Django 1.6 the GenericIPAddresseField, IPAddressField, SlugField, and
URLField form fields which use these validators all strip the input, so
the possibility of newlines entering your data only exists if you are
using these validators outside of the form fields.
The undocumented, internally unused validate\_integer() function is now
stricter as it validates using a regular expression instead of simply
casting the value using int() and checking if an exception was raised.
Denial-of-service possibility in URL validation (CVE-2015-5145)
django.core.validators.URLValidator included a regular expression that
was extremely slow to evaluate against certain inputs. This regular
expression has been simplified and optimized.
Affected supported versions
•Django master development branch
•Django 1.8
•Django 1.7 (except the URL DoS issue)
•Django 1.4 (except the URL DoS issue)
Per our supported versions policy, Django 1.5 and 1.6 are no longer
receiving security updates.
Reference:
https://www.djangoproject.com/weblog/2015/jul/08/security-releases/
*(from redmine: issue id 4436, created on 2015-07-10, closed on 2015-07-31)*
* Relations:
* parent #4435
* Changesets:
* Revision dd8cfc39e66141462d8826eea3678076d16dca6b by Natanael Copa on 2015-07-14T13:51:22Z:
```
main/py-django: security upgrade to 1.8.3 (CVE-2015-5143)
ref #4435
fixes #4436
(cherry picked from commit 79b0aaea9ac5f1e44d437aa26cf01d4e3ab484a5)
```3.2.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4435django: Denial-of-service possibility by filling session store (CVE-2015-5143...2019-07-23T13:50:42ZAlexander Belousdjango: Denial-of-service possibility by filling session store (CVE-2015-5143, CVE-2015-5144, CVE-2015-5145)Denial-of-service possibility by filling session store (CVE-2015-5143)
>In previous versions of Django, the session backends created a new
empty record in the session storage anytime request.session was accessed
and there was a session ...Denial-of-service possibility by filling session store (CVE-2015-5143)
>In previous versions of Django, the session backends created a new
empty record in the session storage anytime request.session was accessed
and there was a session key provided in the request cookies that didn’t
already have a session record. This could allow an attacker to easily
create many new session records simply by sending repeated requests with
unknown session keys, potentially filling up the session store or
causing other users’ session records to be evicted.
>
>The built-in session backends now create a session record only if
the session is actually modified; empty session records are not created.
Thus this potential DoS is now only possible if the site chooses to
expose a session-modifying view to anonymous users.
>
>As each built-in session backend was fixed separately (rather than
a fix in the core sessions framework), maintainers of third-party
session backends should check whether the same vulnerability is present
in their backend and correct it if so.
Header injection possibility since validators accept newlines in input
(CVE-2015-5144)
>Some of Django’s built-in validators
(django.core.validators.EmailValidator, most seriously) didn’t prohibit
newline characters (due to the usage of $ instead of \\Z in the regular
expressions). If you use values with newlines in HTTP response or email
headers, you can suffer from header injection attacks. Django itself
isn’t vulnerable because django.http.HttpResponse and the mail sending
utilities in django.core.mail prohibit newlines in HTTP and SMTP
headers, respectively. While the validators have been fixed in Django,
if you’re creating HTTP responses or email messages in other ways, it’s
a good idea to ensure that those methods prohibit newlines as well. You
might also want to validate that any existing data in your application
doesn’t contain unexpected newlines.
>
>django.core.validators.validate\_ipv4\_address(),
django.core.validators.validate\_slug(), and
django.core.validators.URLValidator are also affected, however, as of
Django 1.6 the GenericIPAddresseField, IPAddressField, SlugField, and
URLField form fields which use these validators all strip the input, so
the possibility of newlines entering your data only exists if you are
using these validators outside of the form fields.
>
>The undocumented, internally unused validate\_integer() function is
now stricter as it validates using a regular expression instead of
simply casting the value using int() and checking if an exception was
raised.
Denial-of-service possibility in URL validation (CVE-2015-5145)
>django.core.validators.URLValidator included a regular expression
that was extremely slow to evaluate against certain inputs. This regular
expression has been simplified and optimized.
Affected supported versions
•Django master development branch
•Django 1.8
•Django 1.7 (except the URL DoS issue)
•Django 1.4 (except the URL DoS issue)
Per our supported versions policy, **Django 1.5** and 1.6 are no longer
receiving security updates.
Reference:
>https://www.djangoproject.com/weblog/2015/jul/08/security-releases/
*(from redmine: issue id 4435, created on 2015-07-10, closed on 2015-07-31)*
* Relations:
* child #4436
* child #4437
* Changesets:
* Revision 79b0aaea9ac5f1e44d437aa26cf01d4e3ab484a5 by Natanael Copa on 2015-07-14T13:49:45Z:
```
main/py-django: security upgrade to 1.8.3 (CVE-2015-5143)
ref #4435
```
* Revision dd8cfc39e66141462d8826eea3678076d16dca6b by Natanael Copa on 2015-07-14T13:51:22Z:
```
main/py-django: security upgrade to 1.8.3 (CVE-2015-5143)
ref #4435
fixes #4436
(cherry picked from commit 79b0aaea9ac5f1e44d437aa26cf01d4e3ab484a5)
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/4434zfs-grsec builds modules in wrong directory on Alpine 3.2.12019-07-23T13:50:43ZThomas Zelchzfs-grsec builds modules in wrong directory on Alpine 3.2.1Hi,
the zfs-grsec Package is unfortunately building the zfs kernel modules
in a wrong directory, since upgrading to Alpine 3.2.1:
backup:/lib/modules\# ls -l
total 8
drwxr-xr-x 3 root root 4096 Jul 9 20:26 3.18.17
drwxr-xr-x 3 ro...Hi,
the zfs-grsec Package is unfortunately building the zfs kernel modules
in a wrong directory, since upgrading to Alpine 3.2.1:
backup:/lib/modules\# ls -l
total 8
drwxr-xr-x 3 root root 4096 Jul 9 20:26 3.18.17
drwxr-xr-x 3 root root 4096 Jul 9 20:26 3.18.17-0-grsec
backup:/lib/modules\# ls -l 3.18.17/extra/
total 32
drwxr-xr-x 2 root root 4096 Jul 9 20:26 avl
drwxr-xr-x 2 root root 4096 Jul 9 20:26 nvpair
drwxr-xr-x 2 root root 4096 Jul 9 20:26 spl
drwxr-xr-x 2 root root 4096 Jul 9 20:26 splat
drwxr-xr-x 2 root root 4096 Jul 9 20:26 unicode
drwxr-xr-x 2 root root 4096 Jul 9 20:26 zcommon
drwxr-xr-x 2 root root 4096 Jul 9 20:26 zfs
drwxr-xr-x 2 root root 4096 Jul 9 20:26 zpios
I have manually fixed this on my system for now.
It would be great if the package could be fixed.
*(from redmine: issue id 4434, created on 2015-07-09, closed on 2015-07-14)*
* Relations:
* relates #2832
* Changesets:
* Revision 521fc31bda433360f39180603b463ea38c48e303 by Natanael Copa on 2015-07-14T08:53:43Z:
```
main/linux-grsec: fix generated utsrelease.h
ref #4434
```
* Revision 1584bc0ad0464c8b6e7dd15de224a241086dc110 by Natanael Copa on 2015-07-14T09:05:05Z:
```
testing/spl: upgrade ot 0.6.4.2, rename -utils subpackage
ref #4434
```
* Revision f67db05808ee9d0e09284cc98bb3172bf274cde7 by Natanael Copa on 2015-07-14T09:12:24Z:
```
testing/zfs-grsec: upgrade to 0.6.4.2 and rename zfs-utils
ref #4434
```
* Revision b6fb8dadf25838f8fd8fa0542853236d75a63b7d by Natanael Copa on 2015-07-14T12:36:00Z:
```
main/linux-grsec: fix generated utsrelease.h
fixes #4434
(cherry picked from commit 521fc31bda433360f39180603b463ea38c48e303)
```
* Revision 452cee9196c3c3d693c5c95f8efdae3b6d5a14f9 by Natanael Copa on 2015-07-14T12:36:16Z:
```
testing/spl: upgrade ot 0.6.4.2, rename -utils subpackage
ref #4434
(cherry picked from commit 1584bc0ad0464c8b6e7dd15de224a241086dc110)
```
* Revision e3fdc2c59b86a0495d268d5c2646205546178b6b by Natanael Copa on 2015-07-14T12:36:16Z:
```
testing/zfs-grsec: upgrade to 0.6.4.2 and rename zfs-utils
ref #4434
(cherry picked from commit f67db05808ee9d0e09284cc98bb3172bf274cde7)
```3.2.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4433testing/ecryptfs-utils needs to be updated to point to proper locations2019-07-15T14:23:36ZThomas Harningtesting/ecryptfs-utils needs to be updated to point to proper locationsThe internal ecryptfs utility scripts point to paths such as
/sbin/mount.ecryptfs\_private however the relevant files are installed
in /usr/bin
These need to be updated in order for the scripts to operate correctly.
Specific version of...The internal ecryptfs utility scripts point to paths such as
/sbin/mount.ecryptfs\_private however the relevant files are installed
in /usr/bin
These need to be updated in order for the scripts to operate correctly.
Specific version of ecryptfs-utils used: 104-r0
*(from redmine: issue id 4433, created on 2015-07-08)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4432testing/ecryptfs-utils needs gettext added as a dependency2019-07-14T18:29:23ZThomas Harningtesting/ecryptfs-utils needs gettext added as a dependencygettext is used in the utility shell scripts but is not set as a
dependency in the package.
Specific version of ecryptfs-utils used: 104-r0
Low priority as the dependency is easily derived/obtained.
*(from redmine: issue id 4432, cre...gettext is used in the utility shell scripts but is not set as a
dependency in the package.
Specific version of ecryptfs-utils used: 104-r0
Low priority as the dependency is easily derived/obtained.
*(from redmine: issue id 4432, created on 2015-07-08)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4431Update Node.js package to v0.12.62019-07-23T13:50:45ZScott MebbersonUpdate Node.js package to v0.12.6There has been a critical security release for Node.js, v0.12.6
(https://medium.com/@iojs/important-security-upgrades-for-node-js-and-io-js-8ac14ece5852).
Please update the Node.js package to the latest version, 0.12.6
accordingly.
Ho...There has been a critical security release for Node.js, v0.12.6
(https://medium.com/@iojs/important-security-upgrades-for-node-js-and-io-js-8ac14ece5852).
Please update the Node.js package to the latest version, 0.12.6
accordingly.
Homepage: https://nodejs.org/
Source: http://nodejs.org/dist/v0.12.6/node-v0.12.6.tar.gz
*(from redmine: issue id 4431, created on 2015-07-08, closed on 2015-07-08)*
* Changesets:
* Revision 8bdc523ace5ec61cf1ce5429c197f507ec1da64e on 2015-07-08T06:34:20Z:
```
main/nodejs: upgrade to 0.12.6. Fixes #4431
```3.2.1Francesco ColistaFrancesco Colistahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4430Back port encfs and rlog to 3.22019-07-23T13:50:45ZScrumpy JackBack port encfs and rlog to 3.2With the move to gcc 5 in edge, packages in the edge repository may
break in 3.2 when repositories are mixed.
encfs (and the rlog dependancy) are such packages.
*(from redmine: issue id 4430, created on 2015-07-07, closed on 2015-07-...With the move to gcc 5 in edge, packages in the edge repository may
break in 3.2 when repositories are mixed.
encfs (and the rlog dependancy) are such packages.
*(from redmine: issue id 4430, created on 2015-07-07, closed on 2015-07-14)*
* Changesets:
* Revision 7912ad38f953cddc488507aef1d32aa7ee8455c5 by Natanael Copa on 2015-07-14T14:00:19Z:
```
main/rlog: move from testing, claim maintainership
ref #4430
(cherry picked from commit 43e3de7667edd46d5b5448c9c93d304f94e7603d)
```
* Revision 6750a1914733eb5377983d9a9cb5d6441b907204 by Natanael Copa on 2015-07-14T14:02:42Z:
```
main/encfs: move from testing
fixes #4430
(cherry picked from commit a95a74c3c8ffb8b763964a061f1c7f04a717f0f5)
```3.2.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4429main/curl: Adding support for mbedtls2020-01-18T20:54:32ZLeo Unglaubmain/curl: Adding support for mbedtlsHi,
i attached you a patch that builds curl against mbedtls (PolarSSL)
instead of OpenSSL.
Greetings
Leo
*(from redmine: issue id 4429, created on 2015-07-06)*
* Uploads:
* [0001-main-curl-building-against-mbedtls-instead-of-op...Hi,
i attached you a patch that builds curl against mbedtls (PolarSSL)
instead of OpenSSL.
Greetings
Leo
*(from redmine: issue id 4429, created on 2015-07-06)*
* Uploads:
* [0001-main-curl-building-against-mbedtls-instead-of-openss.patch](/uploads/45ba35c67c3884bb3fc0012bb19317f8/0001-main-curl-building-against-mbedtls-instead-of-openss.patch)Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4428XSupportedLocale gives false negatives due to bad default $LANG and bad local...2020-01-18T23:03:17ZRich FelkerXSupportedLocale gives false negatives due to bad default $LANG and bad locale.alias fileThe xlib function XSupportedLocale uses the
/usr/share/X11/locale/locale.alias file to map the string returned by
setlocale to a set of locale names xlib is aware of, and returns false
if it does not find one. I suspect (but have not con...The xlib function XSupportedLocale uses the
/usr/share/X11/locale/locale.alias file to map the string returned by
setlocale to a set of locale names xlib is aware of, and returns false
if it does not find one. I suspect (but have not confirmed) that it also
chooses its idea of the locale’s character encoding based on the name
that results from this mapping.
The default $LANG from /etc/profile is malformed (en.utf8) and is
probably cruft from the uClibc days. It is not recognized by the
locale.alias file, so it breaks programs that rely on xlib locale
functionality.
Previously, musl ignored the locale name passed to setlocale (except for
LC\_MESSAGES) and just returned “C.UTF-8” as the current locale name.
The locale.alias file provides a suitable mapping for this name, so
everything roughly worked. With recent additions to musl’s locale
functionality, the locale name passed by the application or from the
environment is saved and returned by setlocale. Therefore, xlib now sees
“en.utf8” and breaks.
The bad default should just be removed from /etc/profile. In the absence
of any locale env vars, musl will use C.UTF-8, as desired.
But I think the locale.alias file should also be patched. Right now it
maps any locale name without an explicit charset after the dot to a
Latin-1 (ISO8859-1) version of the locale, which is wrong. If xlib is
using the resulting name to assume Latin-1 encoding, bad things will
likely happen in programs which use the X locale system/XInput.
I think locale.alias should be patched to remove all lines with explicit
non-UTF-8 locale names (these are not valid) and to map all names
without explicit charsets to the “.UTF-8” variant. Even better would be
to remove locale.alias entirely and have xlib query
nl\_langinfo(CODESET) to determine the encoding rather than hard-coding
assumptions about locales based on their names. This patch would be
appropriate for upstreaming.
*(from redmine: issue id 4428, created on 2015-07-05)*
* Changesets:
* Revision ee65d272cda3aee4ac47ac67433ee7853d35702a by Natanael Copa on 2015-07-10T06:37:28Z:
```
main/alpine-baselayout: misc fixes
- suggest the setup-alpine command in motd
- fix sysctl location and contents
put sysctl to /etc/sysctl.d with 00 prefix so later sysctl.d files can
override it if needed.
also remove ip_forward, it default to zero in kernel, and is controlled
by iptables init.d or quagga.
- mkmntdirs: add missing header
string.h is needed for strcmp definition
- profile: remove LANG. ref #4428
```
* Revision 88bc7e0870aa598ac3cee8391c6a39a92f44435f by Natanael Copa on 2015-07-10T11:06:06Z:
```
main/alpine-baselayout: misc fixes
- suggest the setup-alpine command in motd
- fix sysctl location and contents
put sysctl to /etc/sysctl.d with 00 prefix so later sysctl.d files can
override it if needed.
also remove ip_forward, it default to zero in kernel, and is controlled
by iptables init.d or quagga.
- mkmntdirs: add missing header
string.h is needed for strcmp definition
- profile: remove LANG. ref #4428
(cherry picked from commit ee65d272cda3aee4ac47ac67433ee7853d35702a)
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/4427Package request: wifi driver rtl8192eu2020-01-18T20:52:25ZV KrishnPackage request: wifi driver rtl8192euWifi Driver (kernel module) “rtl8192eu” missing
Tried usb-wifi-dongle on AlpineLinux 3.1.2
*(from redmine: issue id 4427, created on 2015-07-02)*Wifi Driver (kernel module) “rtl8192eu” missing
Tried usb-wifi-dongle on AlpineLinux 3.1.2
*(from redmine: issue id 4427, created on 2015-07-02)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/4426[package request] dictd and dict2020-01-18T20:51:38ZScrumpy Jack[package request] dictd and dictClient/server software, human language dictionary databases, and tools
supporting the DICT protocol (RFC 2229)
http://sourceforge.net/projects/dict/
*(from redmine: issue id 4426, created on 2015-07-02)*Client/server software, human language dictionary databases, and tools
supporting the DICT protocol (RFC 2229)
http://sourceforge.net/projects/dict/
*(from redmine: issue id 4426, created on 2015-07-02)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/4425xf86-video-vesa seems busted2019-07-15T14:22:40ZAriadne Conillariadne@ariadne.spacexf86-video-vesa seems bustedTrying to run \`startxfce4\` results in:
Assertion failed: key->initialized (../include/privates.h:
dixGetPrivateAddr: 122)
This happens on both grsec and vanilla kernel variants.
*(from redmine: issue id 4425, created on 2015-07-...Trying to run \`startxfce4\` results in:
Assertion failed: key->initialized (../include/privates.h:
dixGetPrivateAddr: 122)
This happens on both grsec and vanilla kernel variants.
*(from redmine: issue id 4425, created on 2015-07-02)*
* Relations:
* relates #5906https://gitlab.alpinelinux.org/alpine/aports/-/issues/4424no x86_64 uefi support enable image2019-07-23T13:50:46Zalgitbotno x86_64 uefi support enable imagehi
the subject tell all
if one of you have a image or howto for boot on uefi x86\_64 usb key
it
will be fine
edge is welcome
thanks
*(from redmine: issue id 4424, created on 2015-07-02, closed on 2016-06-24)*hi
the subject tell all
if one of you have a image or howto for boot on uefi x86\_64 usb key
it
will be fine
edge is welcome
thanks
*(from redmine: issue id 4424, created on 2015-07-02, closed on 2016-06-24)*3.4.1https://gitlab.alpinelinux.org/alpine/aports/-/issues/4423root on lvm boot problem if snapshot of root volume exists2019-07-23T13:50:47ZThomas Zelchroot on lvm boot problem if snapshot of root volume existsHi,
I just upgraded one of my Nodes from 3.1.1 to 3.2.
Before doing this i create an LVM Snapshot of the Rootvolume.
After rebooting the server went straight to the emergency recovery
shell.
All Logical Volumes that don’t have any ...Hi,
I just upgraded one of my Nodes from 3.1.1 to 3.2.
Before doing this i create an LVM Snapshot of the Rootvolume.
After rebooting the server went straight to the emergency recovery
shell.
All Logical Volumes that don’t have any Snapshots have Devices under
/dev/VGNAME/\* as they should have.
Neither the Snapshot nor the Origin Logival Volume have any Devices.
When i execute lvm lvs i can see that the Logical Volumes are there.
I have attached 2 Screenshots where the output in the emergency recovery
shell is visible.
*(from redmine: issue id 4423, created on 2015-07-02, closed on 2019-06-11)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/4422Additional Sounds for freeswitch2019-07-23T13:50:48ZJoao Vitor ArrudaAdditional Sounds for freeswitchIts possible to create 2 new sounds packages for freeswitch based on
their repository?
Only the 8000 Hz version is ok at the moment.
The languages are:
\- French: fr-ca-june
- Portuguese (BRA): pt-BR-karina
The files are available...Its possible to create 2 new sounds packages for freeswitch based on
their repository?
Only the 8000 Hz version is ok at the moment.
The languages are:
\- French: fr-ca-june
- Portuguese (BRA): pt-BR-karina
The files are available in:
http://files.freeswitch.org/releases/sounds/
In both cases the latest version (1.0.51) can be used
*(from redmine: issue id 4422, created on 2015-07-01, closed on 2015-07-08)*
* Changesets:
* Revision 59c22fa03b58ac1efe070f22e6054ee2dc4662ca on 2015-07-02T21:33:51Z:
```
testing/freeswitch-sounds-pt-br-karina-8000: new aport
ref #4422
```
* Revision 1037e75ccb55065e99100d248ca2aed26c1cc12c on 2015-07-07T14:29:10Z:
```
main/freeswitch-sounds-pt-br-karina-8000: move from testing
fixes #4422
(cherry picked from commit 9485fcd2d360167cc28ae121e9840d48c7547681)
```
* Revision 244d70926be696fe7d4491c549aecfe8c8dba562 by Natanael Copa on 2015-07-08T09:06:37Z:
```
main/freeswitch-sounds-fr-*: move from testing
ref #4422
```
* Revision 9014781a74372563006ee028cc731008bc65cbcb by Natanael Copa on 2015-07-08T09:13:25Z:
```
main/freeswitch-sounds-fr-*: move from testing
ref #4422
(cherry picked from commit 244d70926be696fe7d4491c549aecfe8c8dba562)
```
* Revision 54a04c67e08e794c4b0fcbe25403b87318f5535a by Natanael Copa on 2015-07-08T09:14:18Z:
```
main/freeswitch-sounds-fr-ca-june-8000: upgrade to 1.0.51
fixes #4422
(cherry picked from commit 64fb8f27c6db8fee32688fa19b6b6ef867c72cf7)
```3.2.1Alan LacerdaAlan Lacerdahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4421setup-disk does not add 'raid' feature if root device is on lvm and physical ...2019-07-23T13:50:49ZNatanael Copasetup-disk does not add 'raid' feature if root device is on lvm and physical disk is /dev/cciss/* hw raidif lvm is used on top of /dev/cciss/\* hardware raid (typically HP
server) then will setup-disk fail to add the hwraid driver in initramfs
resulting that system does not boot.
*(from redmine: issue id 4421, created on 2015-07-01, close...if lvm is used on top of /dev/cciss/\* hardware raid (typically HP
server) then will setup-disk fail to add the hwraid driver in initramfs
resulting that system does not boot.
*(from redmine: issue id 4421, created on 2015-07-01, closed on 2015-07-08)*
* Changesets:
* Revision e51d4fc223b60b41a3d5748122a547565b347031 by Natanael Copa on 2015-07-07T12:36:15Z:
```
main/alpine-conf: fix issue when for it on lvm on cciss raid
fixes #4421
(cherry picked from commit f06947663b0d988c62c583e121839c62a75c775a)
```
* Revision c0ad60b0f9fdb31bd3398d898ecb653c916d0ef9 by Natanael Copa on 2015-07-15T13:12:04Z:
```
setup-disk: add raid to initfs if root is on lvm
ref #4421
```3.2.1https://gitlab.alpinelinux.org/alpine/aports/-/issues/4420[3.2] squashfs-tools: Integer overflow issue and other flaws (CVE-2015-4645 /...2019-07-23T13:50:50ZAlexander Belous[3.2] squashfs-tools: Integer overflow issue and other flaws (CVE-2015-4645 / CVE-2015-4646)Reference:
https://admin.fedoraproject.org/updates/FEDORA-2015-10750/squashfs-tools-4.3-11.fc22
*(from redmine: issue id 4420, created on 2015-07-01, closed on 2015-08-05)*
* Relations:
* parent #4416
* Changesets:
* Revision ed...Reference:
https://admin.fedoraproject.org/updates/FEDORA-2015-10750/squashfs-tools-4.3-11.fc22
*(from redmine: issue id 4420, created on 2015-07-01, closed on 2015-08-05)*
* Relations:
* parent #4416
* Changesets:
* Revision eda97ba58d739a78737006295c03cbe3d77ebceb by Natanael Copa on 2015-07-07T19:54:55Z:
```
main/squashfs-tools: security fix for CVE-2015-4645/4646
ref #4416
fixes #4420
(cherry picked from commit 10422f18285619f8f57b8b4ab5ca829eb21c115f)
```3.2.1Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4419[3.1] squashfs-tools: Integer overflow issue and other flaws (CVE-2015-4645 /...2019-07-23T13:50:51ZAlexander Belous[3.1] squashfs-tools: Integer overflow issue and other flaws (CVE-2015-4645 / CVE-2015-4646)Reference:
https://admin.fedoraproject.org/updates/FEDORA-2015-10750/squashfs-tools-4.3-11.fc22
*(from redmine: issue id 4419, created on 2015-07-01, closed on 2015-08-05)*
* Relations:
* parent #4416
* Changesets:
* Revision 9b...Reference:
https://admin.fedoraproject.org/updates/FEDORA-2015-10750/squashfs-tools-4.3-11.fc22
*(from redmine: issue id 4419, created on 2015-07-01, closed on 2015-08-05)*
* Relations:
* parent #4416
* Changesets:
* Revision 9bd7c332d0146196029353a2d0253998cd510e49 by Natanael Copa on 2015-08-05T12:53:01Z:
```
main/squashfs-tools: security fix for CVE-2015-4645/4646
ref #4416
fixes #4419
```3.1.5Natanael CopaNatanael Copa