aports issueshttps://gitlab.alpinelinux.org/alpine/aports/-/issues2019-07-23T11:15:47Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9883gitolite: security issue in optional bundle helper ("rsync" command) (CVE-201...2019-07-23T11:15:47ZAlicha CHgitolite: security issue in optional bundle helper ("rsync" command) (CVE-2018-20683)commands/rsync in Gitolite before 3.6.11, if .gitolite.rc enables rsync,
mishandles the rsync command line, which allows
attackers to have a “bad” impact by triggering use of an option other
than -v, -n, -q, or -P.
### References:
ht...commands/rsync in Gitolite before 3.6.11, if .gitolite.rc enables rsync,
mishandles the rsync command line, which allows
attackers to have a “bad” impact by triggering use of an option other
than -v, -n, -q, or -P.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2018-20683
https://github.com/sitaramc/gitolite/blob/master/CHANGELOG
### Patch:
https://github.com/sitaramc/gitolite/commit/5df2b817255ee919991da6c310239e08c8fcc1ae
*(from redmine: issue id 9883, created on 2019-01-21, closed on 2019-01-24)*
* Relations:
* child #9884
* child #9885
* child #9886
* child #9887https://gitlab.alpinelinux.org/alpine/aports/-/issues/9884[3.9] gitolite: security issue in optional bundle helper ("rsync" command) (C...2019-07-23T11:15:46ZAlicha CH[3.9] gitolite: security issue in optional bundle helper ("rsync" command) (CVE-2018-20683)commands/rsync in Gitolite before 3.6.11, if .gitolite.rc enables rsync,
mishandles the rsync command line, which allows
attackers to have a “bad” impact by triggering use of an option other
than -v, -n, -q, or -P.
### References:
ht...commands/rsync in Gitolite before 3.6.11, if .gitolite.rc enables rsync,
mishandles the rsync command line, which allows
attackers to have a “bad” impact by triggering use of an option other
than -v, -n, -q, or -P.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2018-20683
https://github.com/sitaramc/gitolite/blob/master/CHANGELOG
### Patch:
https://github.com/sitaramc/gitolite/commit/5df2b817255ee919991da6c310239e08c8fcc1ae
*(from redmine: issue id 9884, created on 2019-01-21, closed on 2019-01-24)*
* Relations:
* parent #9883
* Changesets:
* Revision 87c443db8dd4907c90a4b6077c6d61946fc30816 by Natanael Copa on 2019-01-23T19:14:38Z:
```
main/gitolite: security upgrade to 3.6.11 (CVE-2018-20683)
fixes #9884
```3.9.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/9885[3.8] gitolite: security issue in optional bundle helper ("rsync" command) (C...2019-07-23T11:15:45ZAlicha CH[3.8] gitolite: security issue in optional bundle helper ("rsync" command) (CVE-2018-20683)commands/rsync in Gitolite before 3.6.11, if .gitolite.rc enables rsync,
mishandles the rsync command line, which allows
attackers to have a “bad” impact by triggering use of an option other
than -v, -n, -q, or -P.
### References:
ht...commands/rsync in Gitolite before 3.6.11, if .gitolite.rc enables rsync,
mishandles the rsync command line, which allows
attackers to have a “bad” impact by triggering use of an option other
than -v, -n, -q, or -P.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2018-20683
https://github.com/sitaramc/gitolite/blob/master/CHANGELOG
### Patch:
https://github.com/sitaramc/gitolite/commit/5df2b817255ee919991da6c310239e08c8fcc1ae
*(from redmine: issue id 9885, created on 2019-01-21, closed on 2019-01-24)*
* Relations:
* parent #9883
* Changesets:
* Revision bac739997662850414a0424662a0241c9d49adbf by Natanael Copa on 2019-01-23T19:40:38Z:
```
main/gitolite: security upgrade to 3.6.11 (CVE-2018-20683)
fixes #9885
```3.8.2https://gitlab.alpinelinux.org/alpine/aports/-/issues/9886[3.7] gitolite: security issue in optional bundle helper ("rsync" command) (C...2019-07-23T11:15:44ZAlicha CH[3.7] gitolite: security issue in optional bundle helper ("rsync" command) (CVE-2018-20683)commands/rsync in Gitolite before 3.6.11, if .gitolite.rc enables rsync,
mishandles the rsync command line, which allows
attackers to have a “bad” impact by triggering use of an option other
than -v, -n, -q, or -P.
### References:
ht...commands/rsync in Gitolite before 3.6.11, if .gitolite.rc enables rsync,
mishandles the rsync command line, which allows
attackers to have a “bad” impact by triggering use of an option other
than -v, -n, -q, or -P.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2018-20683
https://github.com/sitaramc/gitolite/blob/master/CHANGELOG
### Patch:
https://github.com/sitaramc/gitolite/commit/5df2b817255ee919991da6c310239e08c8fcc1ae
*(from redmine: issue id 9886, created on 2019-01-21, closed on 2019-01-24)*
* Relations:
* parent #9883
* Changesets:
* Revision fe8fcf4a19eb9ab3bbe62be030fef8f8db5ccbb1 by Natanael Copa on 2019-01-23T19:42:39Z:
```
main/gitolite: security upgrade to 3.6.11 (CVE-2018-20683)
fixes #9886
```3.7.2https://gitlab.alpinelinux.org/alpine/aports/-/issues/9887[3.6] gitolite: security issue in optional bundle helper ("rsync" command) (C...2019-07-23T11:15:43ZAlicha CH[3.6] gitolite: security issue in optional bundle helper ("rsync" command) (CVE-2018-20683)commands/rsync in Gitolite before 3.6.11, if .gitolite.rc enables rsync,
mishandles the rsync command line, which allows
attackers to have a “bad” impact by triggering use of an option other
than -v, -n, -q, or -P.
### References:
ht...commands/rsync in Gitolite before 3.6.11, if .gitolite.rc enables rsync,
mishandles the rsync command line, which allows
attackers to have a “bad” impact by triggering use of an option other
than -v, -n, -q, or -P.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2018-20683
https://github.com/sitaramc/gitolite/blob/master/CHANGELOG
### Patch:
https://github.com/sitaramc/gitolite/commit/5df2b817255ee919991da6c310239e08c8fcc1ae
*(from redmine: issue id 9887, created on 2019-01-21, closed on 2019-01-24)*
* Relations:
* parent #9883
* Changesets:
* Revision 67f3e45bd49581c9d21308a73dd85f972a57e24c by Natanael Copa on 2019-01-23T19:44:17Z:
```
main/gitolite: security upgrade to 3.6.11 (CVE-2018-20683)
fixes #9887
```3.6.3https://gitlab.alpinelinux.org/alpine/aports/-/issues/9888vis: Search unexpectedly wraps to file head2022-01-21T22:35:16ZWolfgang Corcoran-Mathevis: Search unexpectedly wraps to file headIn Alpine’s version of the vis editor (v0.5 +curses +lua +acl), using
n/N to skip
between search results frequently causes the cursor to jump to the first
occurrence
of the pattern *in the file*, rather than the next match after the
...In Alpine’s version of the vis editor (v0.5 +curses +lua +acl), using
n/N to skip
between search results frequently causes the cursor to jump to the first
occurrence
of the pattern *in the file*, rather than the next match after the
cursor. This
behavior seems to occur most reliably when the pattern contains a
multibyte (i.e.
non-ASCII) character.
Steps to reproduce:
1. Open a file containing multibyte characters and move the cursor to
somewhere near the middle of the file.
2. Search for a multibyte character with the / command, e.g. /“
3. Use ‘n’ to skip forward to the next match.
Result: The search should skip to the first occurrence of the search
pattern
in the entire file.
After discussion on the editor’s IRC channel, it seems that this bug is
present
only in vis builds compiled on Alpine (i.e. both the packaged version
and new
builds from source). It is not present on glibc systems and OpenBSD, to
list two
other systems on which the above steps were tried.
*(from redmine: issue id 9888, created on 2019-01-21)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/9890wireshark: Multiple vulnerabilities (CVE-2019-5716, CVE-2019-5717 CVE-2019-57...2019-07-23T11:15:41ZAlicha CHwireshark: Multiple vulnerabilities (CVE-2019-5716, CVE-2019-5717 CVE-2019-5718, CVE-2019-5719, CVE-2019-5721)CVE-2019-5716: 6LoWPAN dissector crash
--------------------------------------
Affected versions: 2.6.0 to 2.6.5
Fixed versions: 2.6.6
### References:
https://www.wireshark.org/security/wnpa-sec-2019-01.html
https://bugs.wireshark....CVE-2019-5716: 6LoWPAN dissector crash
--------------------------------------
Affected versions: 2.6.0 to 2.6.5
Fixed versions: 2.6.6
### References:
https://www.wireshark.org/security/wnpa-sec-2019-01.html
https://bugs.wireshark.org/bugzilla/show\_bug.cgi?id=15217
### CVE-2019-5717: P\_MUL dissector crash
Affected versions: 2.6.0 to 2.6.5, 2.4.0 to 2.4.11
Fixed versions: 2.6.6, 2.4.12
### References:
https://www.wireshark.org/security/wnpa-sec-2019-02.html
https://bugs.wireshark.org/bugzilla/show\_bug.cgi?id=15337
### CVE-2019-5718: RTSE dissector crash
Affected versions: 2.6.0 to 2.6.5, 2.4.0 to 2.4.11
Fixed versions: 2.6.6, 2.4.12
### References:
https://www.wireshark.org/security/wnpa-sec-2019-03.html
https://bugs.wireshark.org/bugzilla/show\_bug.cgi?id=15373
### CVE-2019-5719: ISAKMP dissector crash
Affected versions: 2.6.0 to 2.6.5, 2.4.0 to 2.4.11
Fixed versions: 2.6.6, 2.4.12
### References:
https://www.wireshark.org/security/wnpa-sec-2019-04.html
https://bugs.wireshark.org/bugzilla/show\_bug.cgi?id=15374
### CVE-2019-5721: ENIP dissector crash
Affected versions: 2.4.0 to 2.4.11
Fixed versions: 2.4.12
### References:
https://bugs.wireshark.org/bugzilla/show\_bug.cgi?id=14470
https://nvd.nist.gov/vuln/detail/CVE-2019-5721
*(from redmine: issue id 9890, created on 2019-01-22, closed on 2019-02-14)*
* Relations:
* child #9891
* child #9892Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9891[3.9] wireshark: Multiple vulnerabilities (CVE-2019-5716, CVE-2019-5717 CVE-2...2019-07-23T11:15:40ZAlicha CH[3.9] wireshark: Multiple vulnerabilities (CVE-2019-5716, CVE-2019-5717 CVE-2019-5718, CVE-2019-5719)CVE-2019-5716: 6LoWPAN dissector crash
--------------------------------------
Affected versions: 2.6.0 to 2.6.5
Fixed versions: 2.6.6
### References:
https://www.wireshark.org/security/wnpa-sec-2019-01.html
https://bugs.wireshark....CVE-2019-5716: 6LoWPAN dissector crash
--------------------------------------
Affected versions: 2.6.0 to 2.6.5
Fixed versions: 2.6.6
### References:
https://www.wireshark.org/security/wnpa-sec-2019-01.html
https://bugs.wireshark.org/bugzilla/show\_bug.cgi?id=15217
### CVE-2019-5717: P\_MUL dissector crash
Affected versions: 2.6.0 to 2.6.5, 2.4.0 to 2.4.11
Fixed versions: 2.6.6, 2.4.12
### References:
https://www.wireshark.org/security/wnpa-sec-2019-02.html
https://bugs.wireshark.org/bugzilla/show\_bug.cgi?id=15337
### CVE-2019-5718: RTSE dissector crash
Affected versions: 2.6.0 to 2.6.5, 2.4.0 to 2.4.11
Fixed versions: 2.6.6, 2.4.12
### References:
https://www.wireshark.org/security/wnpa-sec-2019-03.html
https://bugs.wireshark.org/bugzilla/show\_bug.cgi?id=15373
### CVE-2019-5719: ISAKMP dissector crash
Affected versions: 2.6.0 to 2.6.5, 2.4.0 to 2.4.11
Fixed versions: 2.6.6, 2.4.12
### References:
https://www.wireshark.org/security/wnpa-sec-2019-04.html
https://bugs.wireshark.org/bugzilla/show\_bug.cgi?id=15374
*(from redmine: issue id 9891, created on 2019-01-22, closed on 2019-02-14)*
* Relations:
* parent #9890
* Changesets:
* Revision ee19e3141c505313c267a44ffd031a37bfd4f79c on 2019-01-29T19:16:37Z:
```
community/wireshark: security upgrade to 2.6.6
fixes #9891
```Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9892[3.8] wireshark: Multiple vulnerabilities (CVE-2019-5717, CVE-2019-5718, CVE-...2019-07-23T11:15:39ZAlicha CH[3.8] wireshark: Multiple vulnerabilities (CVE-2019-5717, CVE-2019-5718, CVE-2019-5719, CVE-2019-5721)### CVE-2019-5717: P\_MUL dissector crash
Affected versions: 2.6.0 to 2.6.5, 2.4.0 to 2.4.11
Fixed versions: 2.6.6, 2.4.12
### References:
https://www.wireshark.org/security/wnpa-sec-2019-02.html
https://bugs.wireshark.org/bugzill...### CVE-2019-5717: P\_MUL dissector crash
Affected versions: 2.6.0 to 2.6.5, 2.4.0 to 2.4.11
Fixed versions: 2.6.6, 2.4.12
### References:
https://www.wireshark.org/security/wnpa-sec-2019-02.html
https://bugs.wireshark.org/bugzilla/show\_bug.cgi?id=15337
### CVE-2019-5718: RTSE dissector crash
Affected versions: 2.6.0 to 2.6.5, 2.4.0 to 2.4.11
Fixed versions: 2.6.6, 2.4.12
### References:
https://www.wireshark.org/security/wnpa-sec-2019-03.html
https://bugs.wireshark.org/bugzilla/show\_bug.cgi?id=15373
### CVE-2019-5719: ISAKMP dissector crash
Affected versions: 2.6.0 to 2.6.5, 2.4.0 to 2.4.11
Fixed versions: 2.6.6, 2.4.12
### References:
https://www.wireshark.org/security/wnpa-sec-2019-04.html
https://bugs.wireshark.org/bugzilla/show\_bug.cgi?id=15374
### CVE-2019-5721: ENIP dissector crash
Affected versions: 2.4.0 to 2.4.11
Fixed versions: 2.4.12
### References:
https://bugs.wireshark.org/bugzilla/show\_bug.cgi?id=14470
https://nvd.nist.gov/vuln/detail/CVE-2019-5721
*(from redmine: issue id 9892, created on 2019-01-22, closed on 2019-02-14)*
* Relations:
* parent #98903.8.3Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9893Starting certbot 0.29.1-r0 fails with error2019-07-23T11:15:38ZThomas SchneiderStarting certbot 0.29.1-r0 fails with errorError when starting certbot 0.29.1-r0 (on x86\_64).
ct100-haproxy:~\# certbot —version
Traceback (most recent call last):
File “/usr/bin/certbot”, line 6, in <module>
from pkg\_resources import load\_entry\_point
File “/usr/lib/...Error when starting certbot 0.29.1-r0 (on x86\_64).
ct100-haproxy:~\# certbot —version
Traceback (most recent call last):
File “/usr/bin/certbot”, line 6, in <module>
from pkg\_resources import load\_entry\_point
File “/usr/lib/python2.7/site-packages/pkg\_resources/*init*.py”, line
3126, in <module>
@\_call\_aside
File “/usr/lib/python2.7/site-packages/pkg\_resources/*init*.py”, line
3110, in \_call\_aside
f(**args,**\*kwargs)
File “/usr/lib/python2.7/site-packages/pkg\_resources/*init*.py”, line
3139, in \_initialize\_master\_working\_set
working\_set = WorkingSet.\_build\_master()
File “/usr/lib/python2.7/site-packages/pkg\_resources/*init*.py”, line
581, in \_build\_master
ws.require(*requires*)
File “/usr/lib/python2.7/site-packages/pkg\_resources/*init*.py”, line
898, in require
needed = self.resolve(parse\_requirements(requirements))
File “/usr/lib/python2.7/site-packages/pkg\_resources/*init*.py”, line
784, in resolve
raise DistributionNotFound(req, requirers)
pkg\_resources.DistributionNotFound: The ‘zope.hookable>=4.2.0’
distribution was not found and is required by zope.component
I assume there’s a missing dependency.
zope.hookable is not available
ct100-haproxy:~\# apk search zope
py2-zope-interface-4.5.0-r0
py-zope-event-4.3.0-r0
py3-zope-interface-4.5.0-r0
py-zope-configuration-4.0.2-r0
py-zope-deprecation-4.0.2-r0
py-zope-component-4.5-r0
py-zope-interface-4.5.0-r0
*(from redmine: issue id 9893, created on 2019-01-22, closed on 2019-06-19)*Francesco ColistaFrancesco Colistahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9895libraw: Multiple vulnerabilities (CVE-2018-20363, CVE-2018-20364, CVE-2018-20...2019-07-21T19:33:14ZAlicha CHlibraw: Multiple vulnerabilities (CVE-2018-20363, CVE-2018-20364, CVE-2018-20365, CVE-2018-5817 CVE-2018-5818, CVE-2018-5819)**CVE-2018-20363**: LibRaw::raw2image in libraw\_cxx.cpp in LibRaw
0.19.1
has a NULL pointer dereference.
### References:
https://github.com/LibRaw/LibRaw/issues/193
### Patches:
Fixed by:
https://github.com/LibRaw/LibRaw/commit/7e...**CVE-2018-20363**: LibRaw::raw2image in libraw\_cxx.cpp in LibRaw
0.19.1
has a NULL pointer dereference.
### References:
https://github.com/LibRaw/LibRaw/issues/193
### Patches:
Fixed by:
https://github.com/LibRaw/LibRaw/commit/7e29b9f29449fde30cc878fbb137d61c14bba3a4
Additionally needed:
https://github.com/LibRaw/LibRaw/commit/a7c17cb6bbec1e79f058d84511f9c3b142cbdfa7
**CVE-2018-20364**: LibRaw::copy\_bayer in libraw\_cxx.cpp in LibRaw
0.19.1 has
a NULL pointer dereference.
### References:
https://github.com/LibRaw/LibRaw/issues/194
https://nvd.nist.gov/vuln/detail/CVE-2018-20364
### Patches:
Fixed by:
https://github.com/LibRaw/LibRaw/commit/7e29b9f29449fde30cc878fbb137d61c14bba3a4
Additionally needed:
https://github.com/LibRaw/LibRaw/commit/a7c17cb6bbec1e79f058d84511f9c3b142cbdfa7
**CVE-2018-20365**: LibRaw::raw2image() in libraw\_cxx.cpp has a
heap-based buffer overflow.
### References:
https://github.com/LibRaw/LibRaw/issues/195
https://nvd.nist.gov/vuln/detail/CVE-2018-20365
### Patches:
Fixed by:
https://github.com/LibRaw/LibRaw/commit/7e29b9f29449fde30cc878fbb137d61c14bba3a4
Additionally needed:
https://github.com/LibRaw/LibRaw/commit/a7c17cb6bbec1e79f058d84511f9c3b142cbdfa7
**CVE-2018-5817**: DoS in unpacked\_load\_raw function in
internal/dcraw\_common.cpp
### Fixed In Version:
LibRaw 0.19.1
### References:
https://www.flexera.com/company/secunia-research/advisories/SR-2018-27.html
### Patch:
https://github.com/LibRaw/LibRaw/commit/e67a9862d10ebaa97712f532eca1eb5e2e410a22
**CVE-2018-5818**:DoS in parse\_rollei function in
internal/dcraw\_common.cpp
### Fixed In Version:
0.19.1
### References:
https://www.flexera.com/company/secunia-research/advisories/SR-2018-27.html
### Patch:
https://github.com/LibRaw/LibRaw/commit/e67a9862d10ebaa97712f532eca1eb5e2e410a22
**CVE-2018-5819**: DoS in parse\_sinar\_ia function in
internal/dcraw\_common.cpp
### Fixed In Version:
0.19.1
### References:
https://www.flexera.com/company/secunia-research/advisories/SR-2018-27.html
### Patch:
https://github.com/LibRaw/LibRaw/commit/e67a9862d10ebaa97712f532eca1eb5e2e410a22
*(from redmine: issue id 9895, created on 2019-01-23)*
* Relations:
* child #9896
* child #9897Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9896[3.9] libraw: Multiple vulnerabilities (CVE-2018-20363, CVE-2018-20364, CVE-2...2019-07-23T11:15:35ZAlicha CH[3.9] libraw: Multiple vulnerabilities (CVE-2018-20363, CVE-2018-20364, CVE-2018-20365)**CVE-2018-20363**: LibRaw::raw2image in libraw\_cxx.cpp in LibRaw
0.19.1
has a NULL pointer dereference.
### References:
https://github.com/LibRaw/LibRaw/issues/193
### Patches:
Fixed by:
https://github.com/LibRaw/LibRaw/commit/7e...**CVE-2018-20363**: LibRaw::raw2image in libraw\_cxx.cpp in LibRaw
0.19.1
has a NULL pointer dereference.
### References:
https://github.com/LibRaw/LibRaw/issues/193
### Patches:
Fixed by:
https://github.com/LibRaw/LibRaw/commit/7e29b9f29449fde30cc878fbb137d61c14bba3a4
Additionally needed:
https://github.com/LibRaw/LibRaw/commit/a7c17cb6bbec1e79f058d84511f9c3b142cbdfa7
**CVE-2018-20364**: LibRaw::copy\_bayer in libraw\_cxx.cpp in LibRaw
0.19.1 has
a NULL pointer dereference.
### References:
https://github.com/LibRaw/LibRaw/issues/194
https://nvd.nist.gov/vuln/detail/CVE-2018-20364
### Patches:
Fixed by:
https://github.com/LibRaw/LibRaw/commit/7e29b9f29449fde30cc878fbb137d61c14bba3a4
Additionally needed:
https://github.com/LibRaw/LibRaw/commit/a7c17cb6bbec1e79f058d84511f9c3b142cbdfa7
**CVE-2018-20365**: LibRaw::raw2image() in libraw\_cxx.cpp has a
heap-based buffer overflow.
### References:
https://github.com/LibRaw/LibRaw/issues/195
https://nvd.nist.gov/vuln/detail/CVE-2018-20365
### Patches:
Fixed by:
https://github.com/LibRaw/LibRaw/commit/7e29b9f29449fde30cc878fbb137d61c14bba3a4
Additionally needed:
https://github.com/LibRaw/LibRaw/commit/a7c17cb6bbec1e79f058d84511f9c3b142cbdfa7
*(from redmine: issue id 9896, created on 2019-01-23, closed on 2019-02-14)*
* Relations:
* parent #9895
* Changesets:
* Revision 8d15414054edbac12753bac5da6407d74dd3685f on 2019-01-31T14:26:03Z:
```
community/libraw: security upgrade to 0.19.2
CVE-2018-20363, CVE-2018-20364, CVE-2018-20365
Fixes #9896
```3.9.1Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9897[3.8] libraw: Multiple vulnerabilities (CVE-2018-20363, CVE-2018-20364, CVE-2...2019-07-12T15:43:50ZAlicha CH[3.8] libraw: Multiple vulnerabilities (CVE-2018-20363, CVE-2018-20364, CVE-2018-20365, CVE-2018-5817 CVE-2018-5818, CVE-2018-5819)**CVE-2018-20363**: LibRaw::raw2image in libraw\_cxx.cpp in LibRaw
0.19.1
has a NULL pointer dereference.
### References:
https://github.com/LibRaw/LibRaw/issues/193
### Patches:
Fixed by:
https://github.com/LibRaw/LibRaw/commit/7e...**CVE-2018-20363**: LibRaw::raw2image in libraw\_cxx.cpp in LibRaw
0.19.1
has a NULL pointer dereference.
### References:
https://github.com/LibRaw/LibRaw/issues/193
### Patches:
Fixed by:
https://github.com/LibRaw/LibRaw/commit/7e29b9f29449fde30cc878fbb137d61c14bba3a4
Additionally needed:
https://github.com/LibRaw/LibRaw/commit/a7c17cb6bbec1e79f058d84511f9c3b142cbdfa7
**CVE-2018-20364**: LibRaw::copy\_bayer in libraw\_cxx.cpp in LibRaw
0.19.1 has
a NULL pointer dereference.
### References:
https://github.com/LibRaw/LibRaw/issues/194
https://nvd.nist.gov/vuln/detail/CVE-2018-20364
### Patches:
Fixed by:
https://github.com/LibRaw/LibRaw/commit/7e29b9f29449fde30cc878fbb137d61c14bba3a4
Additionally needed:
https://github.com/LibRaw/LibRaw/commit/a7c17cb6bbec1e79f058d84511f9c3b142cbdfa7
**CVE-2018-20365**: LibRaw::raw2image() in libraw\_cxx.cpp has a
heap-based buffer overflow.
### References:
https://github.com/LibRaw/LibRaw/issues/195
https://nvd.nist.gov/vuln/detail/CVE-2018-20365
### Patches:
Fixed by:
https://github.com/LibRaw/LibRaw/commit/7e29b9f29449fde30cc878fbb137d61c14bba3a4
Additionally needed:
https://github.com/LibRaw/LibRaw/commit/a7c17cb6bbec1e79f058d84511f9c3b142cbdfa7
**CVE-2018-5817**: DoS in unpacked\_load\_raw function in
internal/dcraw\_common.cpp
### Fixed In Version:
LibRaw 0.19.1
### References:
https://www.flexera.com/company/secunia-research/advisories/SR-2018-27.html
### Patch:
https://github.com/LibRaw/LibRaw/commit/e67a9862d10ebaa97712f532eca1eb5e2e410a22
**CVE-2018-5818**:DoS in parse\_rollei function in
internal/dcraw\_common.cpp
### Fixed In Version:
0.19.1
### References:
https://www.flexera.com/company/secunia-research/advisories/SR-2018-27.html
### Patch:
https://github.com/LibRaw/LibRaw/commit/e67a9862d10ebaa97712f532eca1eb5e2e410a22
**CVE-2018-5819**: DoS in parse\_sinar\_ia function in
internal/dcraw\_common.cpp
### Fixed In Version:
0.19.1
### References:
https://www.flexera.com/company/secunia-research/advisories/SR-2018-27.html
### Patch:
https://github.com/LibRaw/LibRaw/commit/e67a9862d10ebaa97712f532eca1eb5e2e410a22
*(from redmine: issue id 9897, created on 2019-01-23, closed on 2019-01-31)*
* Relations:
* parent #98953.8.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9898Build Octave with Java-support2021-03-01T00:52:11ZAlexander FyrdahlBuild Octave with Java-supportThe Octave package is not compiled with Java support.
During compile, the configuration script checks for the environment
variable “JAVA\_HOME”, i.e. the environment variable needs to be present
prior to the build.
From the Octave Wik...The Octave package is not compiled with Java support.
During compile, the configuration script checks for the environment
variable “JAVA\_HOME”, i.e. the environment variable needs to be present
prior to the build.
From the Octave Wiki: “If your installation of Octave does not have Java
support, it needs to be rebuilt from source.”
This could perhaps be solved by adding openjdk to makedepends and
setting the environment variable prior to running configure.
*(from redmine: issue id 9898, created on 2019-01-23)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/9900[3.7] aria2: Metadata and potential password leak (CVE-2019-3500)2019-07-23T11:15:34ZAlicha CH[3.7] aria2: Metadata and potential password leak (CVE-2019-3500)aria2c in aria2 1.33.1, when —log is used, can store an HTTP Basic
Authentication username and password in a file,
which might allow local users to obtain sensitive information by reading
this file.
### References:
https://github.com...aria2c in aria2 1.33.1, when —log is used, can store an HTTP Basic
Authentication username and password in a file,
which might allow local users to obtain sensitive information by reading
this file.
### References:
https://github.com/aria2/aria2/issues/1329
https://nvd.nist.gov/vuln/detail/CVE-2019-3500
### Patch:
https://github.com/aria2/aria2/commit/37368130ca7de5491a75fd18a20c5c5cc641824a
*(from redmine: issue id 9900, created on 2019-01-23, closed on 2019-02-14)*
* Changesets:
* Revision c9121abaed924fada67919adf76a978f6e160b87 on 2019-01-31T13:18:36Z:
```
main/aria2: security fix (CVE-2019-3500)
Fixes #9900
```3.7.2Natanael CopaNatanael Copa2019-01-23https://gitlab.alpinelinux.org/alpine/aports/-/issues/9901incongruend and not working network manager as alpine pointed2020-04-24T08:46:14ZPICCORO Lenz McKAYincongruend and not working network manager as alpine pointedincongruend documentation of inexistent group in alpine.. in any case
network manager doe snot work very well:
<code class="text">
root@alpine:/usr/share/doc/networkmanager$ more README.alpine
To modify system network conne...incongruend documentation of inexistent group in alpine.. in any case
network manager doe snot work very well:
<code class="text">
root@alpine:/usr/share/doc/networkmanager$ more README.alpine
To modify system network connections without the root password: add your user account to the 'plugdev' group.
root@alpine:/usr/share/doc/networkmanager$
</code>
<code class="text">
root@alpine:/usr/share/doc/networkmanager$ cat /etc/group | grep dev
netdev:x:28:general
root@alpine:/usr/share/doc/networkmanager$
</code>
related https://lists.alpinelinux.org/alpine-user/0594.html the wifi
does not wor in desktop unless too many tune of the system (where the
tunes works)
*(from redmine: issue id 9901, created on 2019-01-24)*Ariadne Conillariadne@ariadne.spaceAriadne Conillariadne@ariadne.spacehttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9903grub-mkconfig can't properly setup f2fs root fs2019-07-23T11:15:33ZTaner Tasgrub-mkconfig can't properly setup f2fs root fsMy Alpine (edge) system uses f2fs root file system. After new grub
trigger subsystem, my system became non bootable.
I noticed that grub.cfg configuration uses static device names instead
of partition UUID.
My file system is f2fs and ...My Alpine (edge) system uses f2fs root file system. After new grub
trigger subsystem, my system became non bootable.
I noticed that grub.cfg configuration uses static device names instead
of partition UUID.
My file system is f2fs and it seems this issue is not affected ext4 root
file system (tested).
According to my working setup, grub.cfg must be generated as
`linux /vmlinuz-vanilla root=UUID=... rootfstype=f2fs` instead
`linux /vmlinuz-vanilla root=/dev/sdc3`
*(from redmine: issue id 9903, created on 2019-01-24, closed on 2019-01-29)*
* Changesets:
* Revision cb5d66dfdf57d13714e111eda2ef7f9f552d380d by Natanael Copa on 2019-01-24T18:01:30Z:
```
main/grub: add post-ugprade to import default config
import boot options to /etc/default/grub on upgrade to make sure we can
still boot.
ref #9903
```
* Revision 26b88dbce397bc282c399e39b55cec4579c3b42e by Natanael Copa on 2019-01-25T16:01:44Z:
```
main/grub: backport f2fs support
fixes #9903
```3.9.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/9904DNS-resolving issue with alpine:3.8.12021-07-29T17:23:47ZArtem AntipovDNS-resolving issue with alpine:3.8.1Hi!
I’m facing some troubles in all images based on 3.8.1 (trying 4 images
from different sources)
When i’m trying to resolve a DNS-name that actually a CNAME of another
DNS-name i get an error:
\[root@k8s ~\]\# docker exec -it -u0 ...Hi!
I’m facing some troubles in all images based on 3.8.1 (trying 4 images
from different sources)
When i’m trying to resolve a DNS-name that actually a CNAME of another
DNS-name i get an error:
\[root@k8s ~\]\# docker exec -it -u0 050f2125af26 bash
bash-4.4\# cat /etc/os-release
NAME=“Alpine Linux”
ID=alpine
VERSION\_ID=3.8.1
PRETTY\_NAME=“Alpine Linux v3.8”
HOME\_URL=“http://alpinelinux.org”
BUG\_REPORT\_URL=“http://bugs.alpinelinux.org”
bash-4.4\# nslookup gitlab.test.env 10.130.0.3
Server: 10.130.0.3
Address 1: 10.130.0.3
nslookup: can’t resolve ‘gitlab.test.env’: Name does not resolve
bash-4.4\# exit
\[root@k8s ~\]\# nslookup gitlab.test.env 10.130.0.3
Server: 10.130.0.3
Address: 10.130.0.3\#53
gitlab.test.env canonical name = gitlab-01.test.env.
Name: gitlab-01.test.env
Address: 10.130.4.92
\[root@k8s ~\]\# docker pull alpine:3.8
3.8: Pulling from library/alpine
cd784148e348: Pull complete
Digest:
sha256:46e71df1e5191ab8b8034c5189e325258ec44ea739bba1e5645cff83c9048ff1
Status: Downloaded newer image for alpine:3.8
\[root@k8s ~\]\# docker run -it alpine:3.8 sh
/ \# cat /etc/os-release
NAME=“Alpine Linux”
ID=alpine
VERSION\_ID=3.8.2
PRETTY\_NAME=“Alpine Linux v3.8”
HOME\_URL=“http://alpinelinux.org”
BUG\_REPORT\_URL=“http://bugs.alpinelinux.org”
/ \# nslookup gitlab.test.env 10.130.0.3
Server: 10.130.0.3
Address 1: 10.130.0.3 ns1.test.env
Name: gitlab.test.env
Address 1: 10.130.4.92 gitlab-01.test.env
*(from redmine: issue id 9904, created on 2019-01-24)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/9905apache2: Multiple vulnerabilities (CVE-2018-17189, CVE-2018-17199, CVE-2019-0...2019-07-23T11:15:31ZAlicha CHapache2: Multiple vulnerabilities (CVE-2018-17189, CVE-2018-17199, CVE-2019-0190)CVE-2018-17189: DoS for HTTP/2 connections via slow request bodies
------------------------------------------------------------------
By sending request bodies in a slow loris way to plain resources, the h2
stream for that request unnec...CVE-2018-17189: DoS for HTTP/2 connections via slow request bodies
------------------------------------------------------------------
By sending request bodies in a slow loris way to plain resources, the h2
stream for that request unnecessarily occupied a server
thread cleaning up that incoming data. This affects only HTTP/2
connections. A possible mitigation is to not enable the h2 protocol.
### Fixed In Version:
Apache httpd 2.4.38
### References:
https://httpd.apache.org/security/vulnerabilities\_24.html
CVE-2018-17199: mod\_session\_cookie does not respect expiry time
-----------------------------------------------------------------
In Apache HTTP Server 2.4 release 2.4.37 and prior, mod\_session checks
the session expiry time before decoding the session. This causes
session
expiry time to be ignored for mod\_session\_cookie sessions since the
expiry time is loaded when the session is decoded.
### Fixed In Version:
Apache httpd 2.4.38
### References:
https://httpd.apache.org/security/vulnerabilities\_24.html
CVE-2019-0190: mod\_ssl: remote DoS when used with OpenSSL 1.1.1
----------------------------------------------------------------
A bug exists in the way mod\_ssl handled client renegotiations. A remote
attacker could send a carefully crafted request that would cause
mod\_ssl to enter a loop leading to a denial of service. This bug can be
only triggered with Apache HTTP Server version 2.4.37 when using OpenSSL
version 1.1.1 or later, due to an interaction in changes to handling of
renegotiation attempts.
### Fixed In Version:
Apache httpd 2.4.38
### References:
https://httpd.apache.org/security/vulnerabilities\_24.html
https://seclists.org/oss-sec/2019/q1/82
*(from redmine: issue id 9905, created on 2019-01-24, closed on 2019-01-28)*
* Relations:
* child #9906
* child #9907
* child #9908
* child #9909Kaarle RitvanenKaarle Ritvanenhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9906[3.9] apache2: Multiple vulnerabilities (CVE-2018-17189, CVE-2018-17199, CVE-...2019-07-23T11:15:30ZAlicha CH[3.9] apache2: Multiple vulnerabilities (CVE-2018-17189, CVE-2018-17199, CVE-2019-0190)CVE-2018-17189: DoS for HTTP/2 connections via slow request bodies
------------------------------------------------------------------
By sending request bodies in a slow loris way to plain resources, the h2
stream for that request unnec...CVE-2018-17189: DoS for HTTP/2 connections via slow request bodies
------------------------------------------------------------------
By sending request bodies in a slow loris way to plain resources, the h2
stream for that request unnecessarily occupied a server
thread cleaning up that incoming data. This affects only HTTP/2
connections. A possible mitigation is to not enable the h2 protocol.
### Fixed In Version:
Apache httpd 2.4.38
### References:
https://httpd.apache.org/security/vulnerabilities\_24.html
CVE-2018-17199: mod\_session\_cookie does not respect expiry time
-----------------------------------------------------------------
In Apache HTTP Server 2.4 release 2.4.37 and prior, mod\_session checks
the session expiry time before decoding the session. This causes
session
expiry time to be ignored for mod\_session\_cookie sessions since the
expiry time is loaded when the session is decoded.
### Fixed In Version:
Apache httpd 2.4.38
### References:
https://httpd.apache.org/security/vulnerabilities\_24.html
CVE-2019-0190: mod\_ssl: remote DoS when used with OpenSSL 1.1.1
----------------------------------------------------------------
A bug exists in the way mod\_ssl handled client renegotiations. A remote
attacker could send a carefully crafted request that would cause
mod\_ssl to enter a loop leading to a denial of service. This bug can be
only triggered with Apache HTTP Server version 2.4.37 when using OpenSSL
version 1.1.1 or later, due to an interaction in changes to handling of
renegotiation attempts.
### Fixed In Version:
Apache httpd 2.4.38
### References:
https://httpd.apache.org/security/vulnerabilities\_24.html
https://seclists.org/oss-sec/2019/q1/82
*(from redmine: issue id 9906, created on 2019-01-24, closed on 2019-01-28)*
* Relations:
* parent #9905
* Changesets:
* Revision e82176fd8bf8ac0c0089a9b3daedcd2c52dafea3 on 2019-01-25T19:34:59Z:
```
main/apache2: security upgrade to 2.4.38
fixes #9906
```3.9.0Kaarle RitvanenKaarle Ritvanenhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9907[3.8] apache2: Multiple vulnerabilities (CVE-2018-17189, CVE-2018-17199)2019-07-23T11:15:29ZAlicha CH[3.8] apache2: Multiple vulnerabilities (CVE-2018-17189, CVE-2018-17199)CVE-2018-17189: DoS for HTTP/2 connections via slow request bodies
------------------------------------------------------------------
By sending request bodies in a slow loris way to plain resources, the h2
stream for that request unnec...CVE-2018-17189: DoS for HTTP/2 connections via slow request bodies
------------------------------------------------------------------
By sending request bodies in a slow loris way to plain resources, the h2
stream for that request unnecessarily occupied a server
thread cleaning up that incoming data. This affects only HTTP/2
connections. A possible mitigation is to not enable the h2 protocol.
### Fixed In Version:
Apache httpd 2.4.38
### References:
https://httpd.apache.org/security/vulnerabilities\_24.html
CVE-2018-17199: mod\_session\_cookie does not respect expiry time
-----------------------------------------------------------------
In Apache HTTP Server 2.4 release 2.4.37 and prior, mod\_session checks
the session expiry time before decoding the session. This causes
session
expiry time to be ignored for mod\_session\_cookie sessions since the
expiry time is loaded when the session is decoded.
### Fixed In Version:
Apache httpd 2.4.38
### References:
https://httpd.apache.org/security/vulnerabilities\_24.html
*(from redmine: issue id 9907, created on 2019-01-24, closed on 2019-01-28)*
* Relations:
* parent #9905
* Changesets:
* Revision 1d9e0b6cf8ba241e0cc1da807a574470b5aab156 on 2019-01-25T19:42:17Z:
```
main/apache2: security upgrade to 2.4.38
fixes #9907
```3.8.2Kaarle RitvanenKaarle Ritvanenhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9908[3.7] apache2: Multiple vulnerabilities (CVE-2018-17189, CVE-2018-17199)2019-07-23T11:15:28ZAlicha CH[3.7] apache2: Multiple vulnerabilities (CVE-2018-17189, CVE-2018-17199)CVE-2018-17189: DoS for HTTP/2 connections via slow request bodies
------------------------------------------------------------------
By sending request bodies in a slow loris way to plain resources, the h2
stream for that request unnec...CVE-2018-17189: DoS for HTTP/2 connections via slow request bodies
------------------------------------------------------------------
By sending request bodies in a slow loris way to plain resources, the h2
stream for that request unnecessarily occupied a server
thread cleaning up that incoming data. This affects only HTTP/2
connections. A possible mitigation is to not enable the h2 protocol.
### Fixed In Version:
Apache httpd 2.4.38
### References:
https://httpd.apache.org/security/vulnerabilities\_24.html
CVE-2018-17199: mod\_session\_cookie does not respect expiry time
-----------------------------------------------------------------
In Apache HTTP Server 2.4 release 2.4.37 and prior, mod\_session checks
the session expiry time before decoding the session. This causes
session
expiry time to be ignored for mod\_session\_cookie sessions since the
expiry time is loaded when the session is decoded.
### Fixed In Version:
Apache httpd 2.4.38
### References:
https://httpd.apache.org/security/vulnerabilities\_24.html
*(from redmine: issue id 9908, created on 2019-01-24, closed on 2019-01-28)*
* Relations:
* parent #9905
* Changesets:
* Revision b49cc47cb0358234399a4dee1ad276828120df5b on 2019-01-25T19:52:24Z:
```
main/apache2: security upgrade to 2.4.38
fixes #9908
```3.7.2Kaarle RitvanenKaarle Ritvanenhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9909[3.6] apache2: Multiple vulnerabilities (CVE-2018-17189, CVE-2018-17199)2019-07-23T11:15:27ZAlicha CH[3.6] apache2: Multiple vulnerabilities (CVE-2018-17189, CVE-2018-17199)CVE-2018-17189: DoS for HTTP/2 connections via slow request bodies
------------------------------------------------------------------
By sending request bodies in a slow loris way to plain resources, the h2
stream for that request unnec...CVE-2018-17189: DoS for HTTP/2 connections via slow request bodies
------------------------------------------------------------------
By sending request bodies in a slow loris way to plain resources, the h2
stream for that request unnecessarily occupied a server
thread cleaning up that incoming data. This affects only HTTP/2
connections. A possible mitigation is to not enable the h2 protocol.
### Fixed In Version:
Apache httpd 2.4.38
### References:
https://httpd.apache.org/security/vulnerabilities\_24.html
CVE-2018-17199: mod\_session\_cookie does not respect expiry time
-----------------------------------------------------------------
In Apache HTTP Server 2.4 release 2.4.37 and prior, mod\_session checks
the session expiry time before decoding the session. This causes
session
expiry time to be ignored for mod\_session\_cookie sessions since the
expiry time is loaded when the session is decoded.
### Fixed In Version:
Apache httpd 2.4.38
### References:
https://httpd.apache.org/security/vulnerabilities\_24.html
*(from redmine: issue id 9909, created on 2019-01-24, closed on 2019-01-28)*
* Relations:
* parent #9905
* Changesets:
* Revision 86686eac58e8b2cd03eb04fdcdab2afdd4871e0c on 2019-01-25T20:13:50Z:
```
main/apache2: security upgrade to 2.4.38
fixes #9909
```3.6.3Kaarle RitvanenKaarle Ritvanenhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9910f2fs fails to init when fstab fsck colon set to "1"2021-02-08T12:50:19ZTaner Tasf2fs fails to init when fstab fsck colon set to "1"<code class="text">
UUID=ad615b92-a2a3-4896-bb3c-2c48f68bd3f4 / f2fs defaults 0 1
</code>
The fstab line above fails to init system on f2fs root.If I set to “0 0”
again (no fsck) then system inits as expected.
*(from redmine: ...<code class="text">
UUID=ad615b92-a2a3-4896-bb3c-2c48f68bd3f4 / f2fs defaults 0 1
</code>
The fstab line above fails to init system on f2fs root.If I set to “0 0”
again (no fsck) then system inits as expected.
*(from redmine: issue id 9910, created on 2019-01-24)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/9911setup-alpine needs the time set earlier in the script2019-07-23T11:15:26ZRichard Mortiersetup-alpine needs the time set earlier in the scriptI was installing Alpine 3.8 recently on some old PCs that had been
turned off long enough that the system clocks were years out of date.
The \`setup-alpine\` script tries to contact and select the package
repositories before setting up...I was installing Alpine 3.8 recently on some old PCs that had been
turned off long enough that the system clocks were years out of date.
The \`setup-alpine\` script tries to contact and select the package
repositories before setting up NTP.
Due to the clock being so behind, contacting the repos failed because
the TLS handshake was upset at the time differential (I believe).
CTRL-C out of \`setup-alpine\` at that point (ie., after networking was
setup) and execute \`setup-ntp\` by hand followed by \`setup-alpine\`
again resolved the issue.
But it seems like (if I read \`setup-alpine.in\` correctly),
\`setup-ntp\` might be moved from L.198-200 to L.188, ie., before
\`setup-apkrepos\` (with suitable check for \`$quick\` added) to make
this a little smoother in this case. Happy to produce a patch if that
seems the right thing to do…?
*(from redmine: issue id 9911, created on 2019-01-25, closed on 2019-05-04)*
* Changesets:
* Revision 6f613e0f07777ae01350635aef26816bbcde424b by Natanael Copa on 2019-01-25T15:17:52Z:
```
main/alpine-conf: set up ntp before repos in setup-alpine
we need time to be correct for https certificate validation.
fixes #9911
```
* Revision 8c6d977259da9bbf4f416ddc2195bf22483259b5 by Natanael Copa on 2019-02-21T16:20:43Z:
```
setup-alpine: setup ntp before repos
we need time to be correct for https certificates when setting up
apkrepos, so we call setup-ntp before setup-apkrepos.
ref #9911
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/9914wavpack: Multiple vulnerabilities (CVE-2018-19840, CVE-2018-19841)2019-07-23T11:15:24ZAlicha CHwavpack: Multiple vulnerabilities (CVE-2018-19840, CVE-2018-19841)**CVE-2018-19840**: The function WavpackPackInit in pack\_utils.c in
libwavpack.a in WavPack through 5.1.0 allows attackers to cause a
denial-of-service
(resource exhaustion caused by an infinite loop) via a crafted wav audio
file beca...**CVE-2018-19840**: The function WavpackPackInit in pack\_utils.c in
libwavpack.a in WavPack through 5.1.0 allows attackers to cause a
denial-of-service
(resource exhaustion caused by an infinite loop) via a crafted wav audio
file because WavpackSetConfiguration64 mishandles a sample rate of zero.
### References:
https://github.com/dbry/WavPack/issues/53
### Patch:
https://github.com/dbry/WavPack/commit/070ef6f138956d9ea9612e69586152339dbefe51
**CVE-2018-19841**: The function WavpackVerifySingleBlock in
open\_utils.c in libwavpack.a in WavPack through 5.1.0 allows
attackers to cause a denial-of-service (out-of-bounds read and
application crash) via a crafted WavPack Lossless Audio file,
as demonstrated by wvunpack.
### References:
https://github.com/dbry/WavPack/issues/54
### Patch:
https://github.com/dbry/WavPack/commit/bba5389dc598a92bdf2b297c3ea34620b6679b5b
*(from redmine: issue id 9914, created on 2019-01-25, closed on 2019-02-14)*
* Relations:
* child #9915
* child #9916
* child #9917
* child #9918Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9915[3.9] wavpack: Multiple vulnerabilities (CVE-2018-19840, CVE-2018-19841)2019-07-23T11:15:23ZAlicha CH[3.9] wavpack: Multiple vulnerabilities (CVE-2018-19840, CVE-2018-19841)**CVE-2018-19840**: The function WavpackPackInit in pack\_utils.c in
libwavpack.a in WavPack through 5.1.0 allows attackers to cause a
denial-of-service
(resource exhaustion caused by an infinite loop) via a crafted wav audio
file beca...**CVE-2018-19840**: The function WavpackPackInit in pack\_utils.c in
libwavpack.a in WavPack through 5.1.0 allows attackers to cause a
denial-of-service
(resource exhaustion caused by an infinite loop) via a crafted wav audio
file because WavpackSetConfiguration64 mishandles a sample rate of zero.
### References:
https://github.com/dbry/WavPack/issues/53
### Patch:
https://github.com/dbry/WavPack/commit/070ef6f138956d9ea9612e69586152339dbefe51
**CVE-2018-19841**: The function WavpackVerifySingleBlock in
open\_utils.c in libwavpack.a in WavPack through 5.1.0 allows
attackers to cause a denial-of-service (out-of-bounds read and
application crash) via a crafted WavPack Lossless Audio file,
as demonstrated by wvunpack.
### References:
https://github.com/dbry/WavPack/issues/54
### Patch:
https://github.com/dbry/WavPack/commit/bba5389dc598a92bdf2b297c3ea34620b6679b5b
*(from redmine: issue id 9915, created on 2019-01-25, closed on 2019-02-14)*
* Relations:
* parent #9914
* Changesets:
* Revision f06887bf6720ff8c26e5a7e3b87488cb2be83be2 on 2019-01-31T13:04:24Z:
```
main/wavpack: security fixes (CVE-2018-19840, CVE-2018-19841)
Fixes #9915
```3.9.1Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9916[3.8] wavpack: Multiple vulnerabilities (CVE-2018-19840, CVE-2018-19841)2019-07-23T11:15:22ZAlicha CH[3.8] wavpack: Multiple vulnerabilities (CVE-2018-19840, CVE-2018-19841)**CVE-2018-19840**: The function WavpackPackInit in pack\_utils.c in
libwavpack.a in WavPack through 5.1.0 allows attackers to cause a
denial-of-service
(resource exhaustion caused by an infinite loop) via a crafted wav audio
file beca...**CVE-2018-19840**: The function WavpackPackInit in pack\_utils.c in
libwavpack.a in WavPack through 5.1.0 allows attackers to cause a
denial-of-service
(resource exhaustion caused by an infinite loop) via a crafted wav audio
file because WavpackSetConfiguration64 mishandles a sample rate of zero.
### References:
https://github.com/dbry/WavPack/issues/53
### Patch:
https://github.com/dbry/WavPack/commit/070ef6f138956d9ea9612e69586152339dbefe51
**CVE-2018-19841**: The function WavpackVerifySingleBlock in
open\_utils.c in libwavpack.a in WavPack through 5.1.0 allows
attackers to cause a denial-of-service (out-of-bounds read and
application crash) via a crafted WavPack Lossless Audio file,
as demonstrated by wvunpack.
### References:
https://github.com/dbry/WavPack/issues/54
### Patch:
https://github.com/dbry/WavPack/commit/bba5389dc598a92bdf2b297c3ea34620b6679b5b
*(from redmine: issue id 9916, created on 2019-01-25, closed on 2019-02-14)*
* Relations:
* parent #9914
* Changesets:
* Revision 7cca64b825df9ba1e75a7b5b58c7f189f42e28d1 on 2019-01-31T13:05:39Z:
```
main/wavpack: security fixes (CVE-2018-19840, CVE-2018-19841)
Fixes #9916
```3.8.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9917[3.7] wavpack: Multiple vulnerabilities (CVE-2018-19840, CVE-2018-19841)2019-07-23T11:15:21ZAlicha CH[3.7] wavpack: Multiple vulnerabilities (CVE-2018-19840, CVE-2018-19841)**CVE-2018-19840**: The function WavpackPackInit in pack\_utils.c in
libwavpack.a in WavPack through 5.1.0 allows attackers to cause a
denial-of-service
(resource exhaustion caused by an infinite loop) via a crafted wav audio
file beca...**CVE-2018-19840**: The function WavpackPackInit in pack\_utils.c in
libwavpack.a in WavPack through 5.1.0 allows attackers to cause a
denial-of-service
(resource exhaustion caused by an infinite loop) via a crafted wav audio
file because WavpackSetConfiguration64 mishandles a sample rate of zero.
### References:
https://github.com/dbry/WavPack/issues/53
### Patch:
https://github.com/dbry/WavPack/commit/070ef6f138956d9ea9612e69586152339dbefe51
**CVE-2018-19841**: The function WavpackVerifySingleBlock in
open\_utils.c in libwavpack.a in WavPack through 5.1.0 allows
attackers to cause a denial-of-service (out-of-bounds read and
application crash) via a crafted WavPack Lossless Audio file,
as demonstrated by wvunpack.
### References:
https://github.com/dbry/WavPack/issues/54
### Patch:
https://github.com/dbry/WavPack/commit/bba5389dc598a92bdf2b297c3ea34620b6679b5b
*(from redmine: issue id 9917, created on 2019-01-25, closed on 2019-02-14)*
* Relations:
* parent #9914
* Changesets:
* Revision b5b80b2b87d036148c7314cd653d8cf8f57c9556 on 2019-01-31T13:07:48Z:
```
main/wavpack: security fixes (CVE-2018-19840, CVE-2018-19841)
Fixes #9917
```3.7.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9918[3.6] wavpack: Multiple vulnerabilities (CVE-2018-19840, CVE-2018-19841)2019-07-23T11:15:20ZAlicha CH[3.6] wavpack: Multiple vulnerabilities (CVE-2018-19840, CVE-2018-19841)**CVE-2018-19840**: The function WavpackPackInit in pack\_utils.c in
libwavpack.a in WavPack through 5.1.0 allows attackers to cause a
denial-of-service
(resource exhaustion caused by an infinite loop) via a crafted wav audio
file beca...**CVE-2018-19840**: The function WavpackPackInit in pack\_utils.c in
libwavpack.a in WavPack through 5.1.0 allows attackers to cause a
denial-of-service
(resource exhaustion caused by an infinite loop) via a crafted wav audio
file because WavpackSetConfiguration64 mishandles a sample rate of zero.
### References:
https://github.com/dbry/WavPack/issues/53
### Patch:
https://github.com/dbry/WavPack/commit/070ef6f138956d9ea9612e69586152339dbefe51
**CVE-2018-19841**: The function WavpackVerifySingleBlock in
open\_utils.c in libwavpack.a in WavPack through 5.1.0 allows
attackers to cause a denial-of-service (out-of-bounds read and
application crash) via a crafted WavPack Lossless Audio file,
as demonstrated by wvunpack.
### References:
https://github.com/dbry/WavPack/issues/54
### Patch:
https://github.com/dbry/WavPack/commit/bba5389dc598a92bdf2b297c3ea34620b6679b5b
*(from redmine: issue id 9918, created on 2019-01-25, closed on 2019-02-14)*
* Relations:
* parent #9914
* Changesets:
* Revision e58c4039fb96953e79558384100a86f6a56c32f2 on 2019-01-31T13:09:31Z:
```
main/wavpack: security fixes (CVE-2018-19840, CVE-2018-19841)
Fixes #9918
```3.6.3Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9920dovecot split protocol default config error2019-07-23T11:15:17Zalgitbotdovecot split protocol default config errorhttps://git.alpinelinux.org/aports/tree/main/dovecot/APKBUILD?id=e02aad8c475a7413777e720103c1694f0d5e8487\#n192
instead of concatenating with $protocols, it concatenates with $protocol
fix: append an s to $protocol
please fix before 3...https://git.alpinelinux.org/aports/tree/main/dovecot/APKBUILD?id=e02aad8c475a7413777e720103c1694f0d5e8487\#n192
instead of concatenating with $protocols, it concatenates with $protocol
fix: append an s to $protocol
please fix before 3.9 is released, because the default config is broken
now (complaint by doveconf)
*(from redmine: issue id 9920, created on 2019-01-26, closed on 2019-01-29)*
* Changesets:
* Revision 6cfc6137d7936ef4e37fa4ca269b560a001936ca by Jakub Jirutka on 2019-01-26T17:05:56Z:
```
main/dovecot: fix typo $protocol -> $protocols
Fixes #9920 (https://bugs.alpinelinux.org/issues/9920)
```3.9.0Jakub JirutkaJakub Jirutkahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9922`udisksctl status` fails without the dbus daemon2019-07-23T10:34:50ZAntoine d'Otreppe`udisksctl status` fails without the dbus daemonSummary:
**udisksctl** fails to run with a fresh install of package **udisks2**.
$ udisksctl status
Error connecting to the udisks daemon: Could not connect: No such file or directory
Solution:
It seems the **dbus** daemon m...Summary:
**udisksctl** fails to run with a fresh install of package **udisks2**.
$ udisksctl status
Error connecting to the udisks daemon: Could not connect: No such file or directory
Solution:
It seems the **dbus** daemon must be installed and running.
$ apk add dbus
$ /etc/init.d/dbus start
Suggestion:
Maybe the **dbus** package should be added as a dependency/recommended
package when installing **udisks2**.
Platform:
RaspberryPi 3b+, Alpine 3.8 installed and upgraded
Linux <hostname> 4.14.89-0-rpi \#1-Alpine SMP PREEMPT Tue Dec 18
17:25:49 UTC 2018 aarch64 Linux
*(from redmine: issue id 9922, created on 2019-01-26)*LeoLeohttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9925Update i386/alpine:edge image in docker hub2020-04-10T20:05:53ZJohn SmithUpdate i386/alpine:edge image in docker hubI’ve noticed that i386 image of alpine:edge in docker hub is based on
alpine 3.7:
docker run —rm -it —entrypoint= i386/alpine:edge sh
/ \# cat /etc/alpine-release
3.7.0
but edge should be based on 3.9 nowadays.
x86\_64 version of ...I’ve noticed that i386 image of alpine:edge in docker hub is based on
alpine 3.7:
docker run —rm -it —entrypoint= i386/alpine:edge sh
/ \# cat /etc/alpine-release
3.7.0
but edge should be based on 3.9 nowadays.
x86\_64 version of that image is built properly.
*(from redmine: issue id 9925, created on 2019-01-26)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/9928sysctl scripts not run at boot time2020-03-16T01:55:21ZOliver Dittmersysctl scripts not run at boot timeSysctl doesn’t seem to run kernel parameters at boot time. Either
manually entering “sysctl -p” or running “service sysctl restart” will
load the parameters set in /etc/sysctl.conf or under /etc/sysctl.d/
The readme files and https://wi...Sysctl doesn’t seem to run kernel parameters at boot time. Either
manually entering “sysctl -p” or running “service sysctl restart” will
load the parameters set in /etc/sysctl.conf or under /etc/sysctl.d/
The readme files and https://wiki.alpinelinux.org/wiki/Sysctl.conf seem
to indicate that this is not the expected behavior.
*(from redmine: issue id 9928, created on 2019-01-27)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9930subversion: malicious SVN clients can crash mod_dav_svn (CVE-2018-11803)2019-07-23T11:15:13ZAlicha CHsubversion: malicious SVN clients can crash mod_dav_svn (CVE-2018-11803)Subversion 1.10.0 introduced server-side support for recursive directory
listing operations. The implementation in mod\_dav\_svn failed to
validate the root path of the directory listing provided by the client.
If the client omits the ro...Subversion 1.10.0 introduced server-side support for recursive directory
listing operations. The implementation in mod\_dav\_svn failed to
validate the root path of the directory listing provided by the client.
If the client omits the root path, mod\_dav\_svn will deference an
uninitialized pointer variable and crash the HTTPD worker process
handling the request.
### Fixed In Version:
subversion 1.10.4, subversion 1.11.1
### References:
https://subversion.apache.org/security/CVE-2018-11803-advisory.txt
*(from redmine: issue id 9930, created on 2019-01-28, closed on 2019-01-28)*
* Relations:
* child #9931
* child #9932Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9931[3.9] subversion: malicious SVN clients can crash mod_dav_svn (CVE-2018-11803)2019-07-23T11:15:12ZAlicha CH[3.9] subversion: malicious SVN clients can crash mod_dav_svn (CVE-2018-11803)Subversion 1.10.0 introduced server-side support for recursive directory
listing operations. The implementation in mod\_dav\_svn failed to
validate the root path of the directory listing provided by the client.
If the client omits the ro...Subversion 1.10.0 introduced server-side support for recursive directory
listing operations. The implementation in mod\_dav\_svn failed to
validate the root path of the directory listing provided by the client.
If the client omits the root path, mod\_dav\_svn will deference an
uninitialized pointer variable and crash the HTTPD worker process
handling the request.
### Fixed In Version:
subversion 1.10.4, subversion 1.11.1
### References:
https://subversion.apache.org/security/CVE-2018-11803-advisory.txt
*(from redmine: issue id 9931, created on 2019-01-28, closed on 2019-01-28)*
* Relations:
* parent #9930
* Changesets:
* Revision 7bb81a1376cc08d7e60a7b33e4d6ac28d0a4df12 on 2019-01-28T16:15:54Z:
```
main/subversion: security upgrade to 1.11.1
fixes #9931
```3.9.1Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9932[3.8] subversion: malicious SVN clients can crash mod_dav_svn (CVE-2018-11803)2019-07-23T11:15:11ZAlicha CH[3.8] subversion: malicious SVN clients can crash mod_dav_svn (CVE-2018-11803)Subversion 1.10.0 introduced server-side support for recursive directory
listing operations. The implementation in mod\_dav\_svn failed to
validate the root path of the directory listing provided by the client.
If the client omits the ro...Subversion 1.10.0 introduced server-side support for recursive directory
listing operations. The implementation in mod\_dav\_svn failed to
validate the root path of the directory listing provided by the client.
If the client omits the root path, mod\_dav\_svn will deference an
uninitialized pointer variable and crash the HTTPD worker process
handling the request.
### Fixed In Version:
subversion 1.10.4, subversion 1.11.1
### References:
https://subversion.apache.org/security/CVE-2018-11803-advisory.txt
*(from redmine: issue id 9932, created on 2019-01-28, closed on 2019-01-28)*
* Relations:
* parent #9930
* Changesets:
* Revision d1a2d86a899fff4752652cc14f5afd245cc48cb1 on 2019-01-28T16:17:52Z:
```
main/subversion: security upgrade to 1.10.4
fixes #9932
```3.8.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9933additional modules needed by vanilla kernel to run on (at least) 2015-2017 ma...2019-09-23T12:26:14ZScott Mcdermottadditional modules needed by vanilla kernel to run on (at least) 2015-2017 macbook prosIn bug \#9889 the kernel module hid-apple.ko was requested. After
booting with it in the released 3.9.0-rc5, the keyboard still does not
work. More drivers are required on at least a 12,1 (late 2015) and there
is a 14,1 here (2017 no tou...In bug \#9889 the kernel module hid-apple.ko was requested. After
booting with it in the released 3.9.0-rc5, the keyboard still does not
work. More drivers are required on at least a 12,1 (late 2015) and there
is a 14,1 here (2017 no touchbar) which can be tested next after Alpine
moves to 4.20 kernel (machine boots already without keyboard, but
framebuffer has to be disabled with i915.modeset=0, only kernel 4.20
contains the fix).
Here is the loaded kernel module delta between a running 4.19.0 debian
kernel on a macbook 12,1 and the list of available modules in
linux-vanilla-4.19.18-r0.apk:
intel_rapl
efi_pstore
x86_pkg_temp_thermal
intel_powerclamp
intel_uncore
efivars
spi_pxa2xx_pci
spi_pxa2xx_platform
md_mod
usb_common
In particular, the spi\_foo are needed for the keyboard on 12,1 and I
think will also work on the 14,1 if my memory is correct (tested debian
on it before), The others look like power management which may be more
generally useful on other platforms, and the EFI stuff has some
usefulness on those systems (which includes Macbooks). This is probably
not a complete list of all the drivers the machine can use, but should
be a start.
Note that acpi\_als.ko, industrialio.ko and kfifo\_buf.ko were removed
from the running kernel before obtaining the list, not sure what these
are, system seems fine without them, may have something to do with
webcam? (don’t use). Likewise apple\_bl.ko is used for nvidia which is
not on my hardware (some 15" have it macbook pros have it, but probably
need bunch of others anyways)
**already compiled into vanilla** with =y, so ignore:
\- CONFIG\_BLK\_DEV\_MD=y (drivers/md/md-mod.ko)
- CONFIG\_USB\_COMMON=y (drivers/usb/common/usb-common.ko)
**missing entirely from vanilla** config (patchlevel difference?), not
sure the action:
\- CONFIG\_INTEL\_RAPL (drivers/powercap/intel\_rapl.ko)
\- CONFIG\_EFI\_VARS\_PSTORE (drivers/firmware/efi/efi\_pstore.ko)
- CONFIG\_X86\_PKG\_TEMP\_THERMAL
(drivers/thermal/x86\_pkg\_temp\_thermal.ko)
**requesting to add to vanilla** kernel config (=m):
\- CONFIG\_EFI\_VARS (drivers/firmware/efi/efivars.ko)
\- CONFIG\_INTEL\_POWERCLAMP (drivers/thermal/intel\_powerclamp.ko)
\- CONFIG\_PERF\_EVENTS\_INTEL\_UNCORE
(arch/x86/events/intel/intel-uncore.ko)
\- CONFIG\_SPI\_PXA2XX (drivers/spi/spi-pxa2xx-platform.ko)
- CONFIG\_SPI\_PXA2XX\_PCI (drivers/spi/spi-pxa2xx-pci.ko)
that should get further on the 12,1 model, especially the spi\_pxa2xx
drivers need to be in the initramfs for keyboard. However, kernel 4.20
is really needed to boot the 14,1 laptop; will test it later once 4.20
lands in Alpine.
*(from redmine: issue id 9933, created on 2019-01-29)*
* Relations:
* child #99382019-01-29https://gitlab.alpinelinux.org/alpine/aports/-/issues/9936go: crypto/elliptic implementations of P-521 and P-384 elliptic curves allow ...2019-07-23T11:15:09ZAlicha CHgo: crypto/elliptic implementations of P-521 and P-384 elliptic curves allow for denial of service (CVE-2019-6486)Go before versions 1.10.8 and 1.11.5 has a vulnerability in the
crypto/elliptic implementations of the P-521 and P-384 elliptic
curves.
A remote attacker can exploit this by crafting inputs that consume
excessive amounts of CPU. Th...Go before versions 1.10.8 and 1.11.5 has a vulnerability in the
crypto/elliptic implementations of the P-521 and P-384 elliptic
curves.
A remote attacker can exploit this by crafting inputs that consume
excessive amounts of CPU. These inputs might be delivered via TLS
handshakes, X.509 certificates, JWT tokens, ECDH shares or ECDSA
signatures. In some cases, if an ECDH private key is reused more than
once, the attack can also lead to key recovery.
### Fixed In Version:
golang 1.10.8, golang 1.11.5
### References:
https://groups.google.com/forum/m/\#!topic/golang-announce/mVeX35iXuSw
https://github.com/golang/go/issues/29903
### Patch:
https://github.com/golang/go/commit/42b42f71
*(from redmine: issue id 9936, created on 2019-01-29, closed on 2019-02-14)*
* Relations:
* child #9937Natanael CopaNatanael Copa2019-01-29https://gitlab.alpinelinux.org/alpine/aports/-/issues/9937[3.9] go: crypto/elliptic implementations of P-521 and P-384 elliptic curves ...2019-07-23T11:15:08ZAlicha CH[3.9] go: crypto/elliptic implementations of P-521 and P-384 elliptic curves allow for denial of service (CVE-2019-6486)Go before versions 1.10.8 and 1.11.5 has a vulnerability in the
crypto/elliptic implementations of the P-521 and P-384 elliptic
curves.
A remote attacker can exploit this by crafting inputs that consume
excessive amounts of CPU. Th...Go before versions 1.10.8 and 1.11.5 has a vulnerability in the
crypto/elliptic implementations of the P-521 and P-384 elliptic
curves.
A remote attacker can exploit this by crafting inputs that consume
excessive amounts of CPU. These inputs might be delivered via TLS
handshakes, X.509 certificates, JWT tokens, ECDH shares or ECDSA
signatures. In some cases, if an ECDH private key is reused more than
once, the attack can also lead to key recovery.
### Fixed In Version:
golang 1.10.8, golang 1.11.5
### References:
https://groups.google.com/forum/m/\#!topic/golang-announce/mVeX35iXuSw
https://github.com/golang/go/issues/29903
### Patch:
https://github.com/golang/go/commit/42b42f71
*(from redmine: issue id 9937, created on 2019-01-29, closed on 2019-02-14)*
* Relations:
* parent #9936
* Changesets:
* Revision d37614ce585d5dcfa9ef4b641992dfc998b6574c by Natanael Copa on 2019-01-29T16:31:53Z:
```
community/go: security upgrade to 1.11.5 (CVE-2019-6486)
fixes #9937
```3.9.1Natanael CopaNatanael Copa2019-01-29https://gitlab.alpinelinux.org/alpine/aports/-/issues/9938[3.8] go: crypto/elliptic implementations of P-521 and P-384 elliptic curves ...2019-07-23T11:15:07ZAlicha CH[3.8] go: crypto/elliptic implementations of P-521 and P-384 elliptic curves allow for denial of service (CVE-2019-6486)Go before versions 1.10.8 and 1.11.5 has a vulnerability in the
crypto/elliptic implementations of the P-521 and P-384 elliptic
curves.
A remote attacker can exploit this by crafting inputs that consume
excessive amounts of CPU. Th...Go before versions 1.10.8 and 1.11.5 has a vulnerability in the
crypto/elliptic implementations of the P-521 and P-384 elliptic
curves.
A remote attacker can exploit this by crafting inputs that consume
excessive amounts of CPU. These inputs might be delivered via TLS
handshakes, X.509 certificates, JWT tokens, ECDH shares or ECDSA
signatures. In some cases, if an ECDH private key is reused more than
once, the attack can also lead to key recovery.
### Fixed In Version:
golang 1.10.8, golang 1.11.5
### References:
https://groups.google.com/forum/m/\#!topic/golang-announce/mVeX35iXuSw
https://github.com/golang/go/issues/29903
### Patch:
https://github.com/golang/go/commit/42b42f71
*(from redmine: issue id 9938, created on 2019-01-29, closed on 2019-02-14)*
* Relations:
* parent #9933
* Changesets:
* Revision 6aedd89e4a16f89a2e01bf4d33ebba35c27f433f on 2019-01-31T12:59:05Z:
```
community/go: security upgrade to 1.10.8 (CVE-2019-6486)
Fixes #9938
```3.8.3Natanael CopaNatanael Copa2019-01-29https://gitlab.alpinelinux.org/alpine/aports/-/issues/9939spice: Off-by-one error in array access in spice/server/memslot.c (CVE-2019-3...2019-07-23T11:15:06ZAlicha CHspice: Off-by-one error in array access in spice/server/memslot.c (CVE-2019-3813)spice versions 0.5.2 through 0.14.1 are vulnerable to an out-of-bounds
read
due to an off-by-one error in memslot\_get\_virt. This may lead to a
denial-of-service, or, in the worst case, code-execution by
unauthenticated
attackers....spice versions 0.5.2 through 0.14.1 are vulnerable to an out-of-bounds
read
due to an off-by-one error in memslot\_get\_virt. This may lead to a
denial-of-service, or, in the worst case, code-execution by
unauthenticated
attackers.
### Fixed In Version:
spice 0.14.2
### References:
https://www.openwall.com/lists/oss-security/2019/01/28/2
*(from redmine: issue id 9939, created on 2019-01-29, closed on 2019-02-14)*
* Relations:
* child #9940
* child #9941
* child #9942
* child #9943Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9940[3.9] spice: Off-by-one error in array access in spice/server/memslot.c (CVE-...2019-07-23T11:15:05ZAlicha CH[3.9] spice: Off-by-one error in array access in spice/server/memslot.c (CVE-2019-3813)spice versions 0.5.2 through 0.14.1 are vulnerable to an out-of-bounds
read
due to an off-by-one error in memslot\_get\_virt. This may lead to a
denial-of-service, or, in the worst case, code-execution by
unauthenticated
attackers....spice versions 0.5.2 through 0.14.1 are vulnerable to an out-of-bounds
read
due to an off-by-one error in memslot\_get\_virt. This may lead to a
denial-of-service, or, in the worst case, code-execution by
unauthenticated
attackers.
### Fixed In Version:
spice 0.14.2
### References:
https://www.openwall.com/lists/oss-security/2019/01/28/2
*(from redmine: issue id 9940, created on 2019-01-29, closed on 2019-02-14)*
* Relations:
* parent #9939
* Changesets:
* Revision 82ef14212f0896798a1855c04bb0aca33a1c8e1c on 2019-01-30T16:04:59Z:
```
main/spice: security fix (CVE-2019-3813)
Fixes #9940
```3.9.1Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9941[3.8] spice: Off-by-one error in array access in spice/server/memslot.c (CVE-...2019-07-23T11:15:04ZAlicha CH[3.8] spice: Off-by-one error in array access in spice/server/memslot.c (CVE-2019-3813)spice versions 0.5.2 through 0.14.1 are vulnerable to an out-of-bounds
read
due to an off-by-one error in memslot\_get\_virt. This may lead to a
denial-of-service, or, in the worst case, code-execution by
unauthenticated
attackers....spice versions 0.5.2 through 0.14.1 are vulnerable to an out-of-bounds
read
due to an off-by-one error in memslot\_get\_virt. This may lead to a
denial-of-service, or, in the worst case, code-execution by
unauthenticated
attackers.
### Fixed In Version:
spice 0.14.2
### References:
https://www.openwall.com/lists/oss-security/2019/01/28/2
*(from redmine: issue id 9941, created on 2019-01-29, closed on 2019-02-14)*
* Relations:
* parent #9939
* Changesets:
* Revision 82adc424bea28cbebf05ecf189452d69b7a82430 on 2019-01-31T11:20:03Z:
```
main/spice: security fix (CVE-2019-3813)
Fixes #9941
```3.8.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9942[3.7] spice: Off-by-one error in array access in spice/server/memslot.c (CVE-...2019-07-23T11:15:03ZAlicha CH[3.7] spice: Off-by-one error in array access in spice/server/memslot.c (CVE-2019-3813)spice versions 0.5.2 through 0.14.1 are vulnerable to an out-of-bounds
read
due to an off-by-one error in memslot\_get\_virt. This may lead to a
denial-of-service, or, in the worst case, code-execution by
unauthenticated
attackers....spice versions 0.5.2 through 0.14.1 are vulnerable to an out-of-bounds
read
due to an off-by-one error in memslot\_get\_virt. This may lead to a
denial-of-service, or, in the worst case, code-execution by
unauthenticated
attackers.
### Fixed In Version:
spice 0.14.2
### References:
https://www.openwall.com/lists/oss-security/2019/01/28/2
*(from redmine: issue id 9942, created on 2019-01-29, closed on 2019-02-14)*
* Relations:
* parent #9939
* Changesets:
* Revision c05d87b3b5549a63d4100ca7a890c0055cca7434 on 2019-01-31T11:24:42Z:
```
main/spice: security fix (CVE-2019-3813)
Fixes #9942
Disable test-qxl-parsing failing on armv7 and ppc64le due to CVE fix
```3.7.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9943[3.6] spice: Off-by-one error in array access in spice/server/memslot.c (CVE-...2019-07-23T11:15:01ZAlicha CH[3.6] spice: Off-by-one error in array access in spice/server/memslot.c (CVE-2019-3813)spice versions 0.5.2 through 0.14.1 are vulnerable to an out-of-bounds
read
due to an off-by-one error in memslot\_get\_virt. This may lead to a
denial-of-service, or, in the worst case, code-execution by
unauthenticated
attackers....spice versions 0.5.2 through 0.14.1 are vulnerable to an out-of-bounds
read
due to an off-by-one error in memslot\_get\_virt. This may lead to a
denial-of-service, or, in the worst case, code-execution by
unauthenticated
attackers.
### Fixed In Version:
spice 0.14.2
### References:
https://www.openwall.com/lists/oss-security/2019/01/28/2
*(from redmine: issue id 9943, created on 2019-01-29, closed on 2019-02-14)*
* Relations:
* parent #9939
* Changesets:
* Revision 298d6f5b5993500c896213f6961102423cde08dc on 2019-01-31T12:47:33Z:
```
main/spice: security fix (CVE-2019-3813)
Fixes #9943
Disable test-qxl-parsing failing on armv7 and ppc64le due to CVE fix
```3.6.3Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9944sudo version 1.8.25_p1-r2 fails2019-07-15T02:47:47ZYaron Shahrabanisudo version 1.8.25_p1-r2 failsThe error message is:
`Error relocating /usr/lib/sudo/libsudo_util.so.0: getentropy: symbol not found`
I found a way to bypass that by commenting out the following line in
`/etc/apk/repositories`:
http://…/edge/main
Then I removed ...The error message is:
`Error relocating /usr/lib/sudo/libsudo_util.so.0: getentropy: symbol not found`
I found a way to bypass that by commenting out the following line in
`/etc/apk/repositories`:
http://…/edge/main
Then I removed `sudo` and installed it back again.
Now the installed version is 1.8.23-r2 and it works as expected.
Is there a chance that the original package (1.8.25\_p1-r2) was compiled
using `glibc`? I’ve looked at some forums and some of them claim it
might be the problem although I couldn’t find this specific error on
Google.
*(from redmine: issue id 9944, created on 2019-01-29)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9947apk installation errors since v3.9.0 upgrade2019-07-23T11:15:00Zalgitbotapk installation errors since v3.9.0 upgradeHi. We’re using Alpine for a Docker container to run unit tests via
Chromium. Yesterday with the 3.9.0 release our build broke with these
errors:
@
…
(10/100) Installing ttf-opensans (1.10-r0)
Executing ttf-opensans-1.10-r0.post-i...Hi. We’re using Alpine for a Docker container to run unit tests via
Chromium. Yesterday with the 3.9.0 release our build broke with these
errors:
@
…
(10/100) Installing ttf-opensans (1.10-r0)
Executing ttf-opensans-1.10-r0.post-install
Error relocating /lib/libuuid.so.1: getrandom: symbol not found@
…
(90/100) Installing gtk+3.0 (3.24.1-r0)
Executing gtk+3.0-3.24.1-r0.post-install
Error relocating /lib/libmount.so.1: getrandom: symbol not found
Error relocating /lib/libuuid.so.1: getrandom: symbol not found
Error relocating /lib/libblkid.so.1: getrandom: symbol not found
…
@
Here’s what our dockerfile is doing:
`RUN apk --no-cache update \
&& echo http://nl.alpinelinux.org/alpine/latest-stable/community >> /etc/apk/repositories \
&& echo http://nl.alpinelinux.org/alpine/latest-stable/main >> /etc/apk/repositories \
&& apk add --no-cache \
git \
chromium \
nss
...`
Downgrading to 3.8 resolves it, so we can do that for now, but I’m
hoping to figure out where the dependencies have gone wrong… Any
pointers for narrowing the problem down would be gratefully received,
thanks!
*(from redmine: issue id 9947, created on 2019-01-30, closed on 2019-05-04)*
* Uploads:
* ![Screen_Shot_2019-01-30_at_16.12.35](/uploads/2513c502ef74378c7ea198d3edafe662/Screen_Shot_2019-01-30_at_16.12.35.png) DockerFile
* ![Screen_Shot_2019-01-30_at_16.15.42](/uploads/82be0a317ce6577122aca133fe483fd5/Screen_Shot_2019-01-30_at_16.15.42.png) Errorhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9948Issue with LibreSSL behind proxy in Alpine docker >3.42019-07-15T02:47:55ZMiro MetsänheimoIssue with LibreSSL behind proxy in Alpine docker >3.4I’ve been building an image which would contain libModSecurity and
nginx. The image builds ok with Apline version 3.4 and OpenSSL, but with
any version above, I get the following error when using git clone (which
uses curl with LibreSSL)...I’ve been building an image which would contain libModSecurity and
nginx. The image builds ok with Apline version 3.4 and OpenSSL, but with
any version above, I get the following error when using git clone (which
uses curl with LibreSSL). The build environment where this is run is
behind a proxy, which I’ve censored below with xxx.xxx.xxx.xxx. For now
I’m staying with the version 3.4.
This is the verbose output of git clone:
<code class="text">
Cloning into '/usr/src/modsecurity'...
* Couldn't find host github.com in the .netrc file; using defaults
* Trying xxx.xxx.xxx.xxx...
* TCP_NODELAY set
* Connected to xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx) port 8080 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to github.com:443
> CONNECT github.com:443 HTTP/1.1
Host: github.com:443
User-Agent: git/2.18.1
Proxy-Connection: Keep-Alive
< HTTP/1.1 200 Connection established
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
* CONNECT phase completed!
* CONNECT phase completed!
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to github.com:443
* Closing connection 0
fatal: unable to access 'https://github.com/SpiderLabs/ModSecurity.git/': LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to github.com:443
</code>
Build steps before the error:
<code class="text">
FROM alpine:3.8
ENV http_proxy http://xxx.xxx.xxx.xxx:8080/
ENV https_proxy http://xxx.xxx.xxx.xxx:8080/
ENV GIT_CURL_VERBOSE=1
COPY build.sh /build.sh
RUN chmod +x /build.sh
RUN sh -c "source /build.sh"
</code>
build.sh (up until the error)
<code class="text">
#!/bin/sh
#break on errors
set -e
#update and install dependencies
apk update
apk add git wget make g++ libffi-dev pcre pcre-dev libressl-dev libtool autoconf apache2-dev libxml2-dev curl-dev automake linux-headers
git config --global http.proxy http://xxx.xxx.xxx.xxx:8080/
git config --global https.proxy http://xxx.xxx.xxx.xxx:8080/
mkdir -p /usr/bin/file
mkdir -p /usr/src/modsecurity
mkdir -p /usr/local/nginx/conf
#make modsecurity
git clone -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity.git /usr/src/modsecurity
</code>
*(from redmine: issue id 9948, created on 2019-01-30)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/9949setup-bootable broken2019-07-23T10:34:56ZCarlo Landmetersetup-bootable brokensetup-bootable -u ./alpine-standard-3.9.0-x86\_64.iso /media/usb
Upgrading /dev/sdd1 from alpine-vanilla-3.5.0 161222 to
alpine-standard-3.9.0 190129
Warning: boot/syslinux/syslinux.cfg: kernel /media/usb/boot/vmlinuz was
not found ...setup-bootable -u ./alpine-standard-3.9.0-x86\_64.iso /media/usb
Upgrading /dev/sdd1 from alpine-vanilla-3.5.0 161222 to
alpine-standard-3.9.0 190129
Warning: boot/syslinux/syslinux.cfg: kernel /media/usb/boot/vmlinuz was
not found
Run /sbin/setup-bootable -c -f /media/usb to fix
mount: /media/usb: mount point is busy.
Warning: Failed to remount as read-only. Is modloop mounted?
*(from redmine: issue id 9949, created on 2019-01-30)*3.9.5Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9951ERROR: tini-static-0.18.0-r0: BAD signature2019-07-14T23:00:41ZJochen PaulERROR: tini-static-0.18.0-r0: BAD signatureI want to run Alpine Linux as Host Os for Docker. When I try to install
Docker, I get
ERROR: tini-static-0.18.0-r0: BAD signature
To be able to install Docker, I add the line
http://dl-cdn.alpinelinux.org/alpine/latest-stable/communit...I want to run Alpine Linux as Host Os for Docker. When I try to install
Docker, I get
ERROR: tini-static-0.18.0-r0: BAD signature
To be able to install Docker, I add the line
http://dl-cdn.alpinelinux.org/alpine/latest-stable/community
to /etc/apk/repositories, perform an apk update and then apk add docker
*(from redmine: issue id 9951, created on 2019-02-01)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/9953cachefilesd cannot start2020-04-23T14:12:10Zalgitbotcachefilesd cannot startNFS caching using cachefilesd does not work. When starting the following
error is printed in the syslog, after which it stops:
Feb 2 20:40:21 alpine daemon.info cachefilesd[4854]: About to bind cache
Feb 2 20:40:21 alpine daem...NFS caching using cachefilesd does not work. When starting the following
error is printed in the syslog, after which it stops:
Feb 2 20:40:21 alpine daemon.info cachefilesd[4854]: About to bind cache
Feb 2 20:40:21 alpine daemon.info cachefilesd[4854]: Bound cache
Feb 2 20:40:21 alpine daemon.notice cachefilesd[4854]: Daemon Started
Feb 2 20:40:21 alpine daemon.err cachefilesd[4854]: unable to set notification on graveyard: errno 22 (Invalid argument)
it happens here:
<code class="c">
static void reap_graveyard(void)
{
/* set a one-shot notification to catch more graves appearing */
reap = 0;
signal(SIGIO, sigio);
if (fcntl(graveyardfd, F_NOTIFY, DN_CREATE) < 0)
oserror("unable to set notification on graveyard");
reap_graveyard_aux(graveyardpath);
}
</code>
see:
https://github.com/jnsnow/cachefilesd/blob/master/cachefilesd.c\#L662
I have no clue how to solve this issue.
Is it alpine or musl specific? Are other people able to get cachefiles
going?
*(from redmine: issue id 9953, created on 2019-02-02)*3.12.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/9954Kernel error messages with 3.9 on RPi 3B/+2021-07-27T23:51:47ZYaron ShahrabaniKernel error messages with 3.9 on RPi 3B/+When booting the system with newly installed 3.9 I’m seeing the
following messages (right below the 4 Raspberries):
[ 0.80290] raspberrypi-firmware soc:firmware: Request 0x00000002 returned status 0x80000001
[ 0.90108] ras...When booting the system with newly installed 3.9 I’m seeing the
following messages (right below the 4 Raspberries):
[ 0.80290] raspberrypi-firmware soc:firmware: Request 0x00000002 returned status 0x80000001
[ 0.90108] raspberrypi-firmware soc:firmware: Request 0x00000003 returned status 0x80000001
(I also have a screenshot).
Previously I used to have a cool splash screen that covered all that,
with the latest version I’m now seeing this error and after that the
splash screen appears.
The kernel version is 4.19.18-0-rpi2 (armv7l).
Anything else I should extract from my system?
*(from redmine: issue id 9954, created on 2019-02-03)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/9955mod_php7.so: symbol not found2020-03-15T09:28:58ZJochen Paulmod_php7.so: symbol not foundI’m trying to install php and apache as described here
https://wiki.alpinelinux.org/wiki/Setting\_Up\_Apache\_with\_PHP. There
is no longer php5 available, so I replaced php5 with php7. The
installation works as expected. No errors durin...I’m trying to install php and apache as described here
https://wiki.alpinelinux.org/wiki/Setting\_Up\_Apache\_with\_PHP. There
is no longer php5 available, so I replaced php5 with php7. The
installation works as expected. No errors during install are reported.
Starting the service results in an error:
httpd: Syntax error on line 480 of /etc/apache2/httpd.conf: Syntax error on line 1 of /etc/apache2/conf.d/php7-module.conf: Cannot load modules/mod_php7.so into server: Error relocating /var/www/modules/mod_php7.so: explicit_bzero: symbol not found
The module is present in
cd /
find . -name mod_php7.so 2>/dev/null
./usr/lib/apache2/mod_php7.so
*(from redmine: issue id 9955, created on 2019-02-03)*3.8.5https://gitlab.alpinelinux.org/alpine/aports/-/issues/9956apk doesn't warn if package already installed as a dependency2019-07-23T11:14:57ZTaner Tasapk doesn't warn if package already installed as a dependency<code class="text">
$ sudo apk add glib-dev
OK: 1408 MiB in 417 packages
$ sudo apk del glib-dev
World updated, but the following packages are not removed due to:
glib-dev: gtk+2.0-dev .makedepends-palemoon dbus-gl...<code class="text">
$ sudo apk add glib-dev
OK: 1408 MiB in 417 packages
$ sudo apk del glib-dev
World updated, but the following packages are not removed due to:
glib-dev: gtk+2.0-dev .makedepends-palemoon dbus-glib-dev cairo-dev pango-dev harfbuzz-dev gdk-pixbuf-dev atk-dev
</code>
According to install task above, glib-dev’s installation status is not
clear. apk should warn that package is going to be added as a
stand-alone package to /etc/apk/world.
Otherwise package and its dependencies will kept by system all time
without any awareness.
*(from redmine: issue id 9956, created on 2019-02-03, closed on 2019-02-03)*3.9.1https://gitlab.alpinelinux.org/alpine/aports/-/issues/9958SSH2 extension not upgrading for PHP7 in 3.112020-04-23T17:42:32ZCiprian DosofteiSSH2 extension not upgrading for PHP7 in 3.11https://pecl.php.net/package/ssh2
Hello —
It appears the SSH2 Pecl extension build shipped with 3.9 is not
compatible with the core PHP7 binaries.
Here is a sample:
/ # apk add php7 php7-ssh2
fetch http://dl-cdn.alpinelinux.o...https://pecl.php.net/package/ssh2
Hello —
It appears the SSH2 Pecl extension build shipped with 3.9 is not
compatible with the core PHP7 binaries.
Here is a sample:
/ # apk add php7 php7-ssh2
fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/x86_64/APKINDEX.tar.gz
(1/10) Installing php7-common (7.2.14-r0)
(2/10) Installing ncurses-terminfo-base (6.1_p20190105-r0)
(3/10) Installing ncurses-terminfo (6.1_p20190105-r0)
(4/10) Installing ncurses-libs (6.1_p20190105-r0)
(5/10) Installing libedit (20181209.3.1-r0)
(6/10) Installing pcre (8.42-r1)
(7/10) Installing libxml2 (2.9.9-r0)
(8/10) Installing php7 (7.2.14-r0)
(9/10) Installing libssh2 (1.8.0-r4)
(10/10) Installing php7-pecl-ssh2 (1.1.2-r3)
Executing busybox-1.29.3-r10.trigger
OK: 20 MiB in 24 packages
/ # php -i | grep -i ssh
PHP Warning: PHP Startup: Unable to load dynamic library 'ssh2.so' (tried: /usr/lib/php7/modules/ssh2.so (Error relocating /usr/lib/php7/modules/ssh2.so: php_ssh2_parse_fopen_modes: symbol not found), /usr/lib/php7/modules/ssh2.so.so (Error loading shared library /usr/lib/php7/modules/ssh2.so.so: No such file or directory)) in Unknown on line 0
Additional .ini files parsed => /etc/php7/conf.d/ssh2.ini
Here is the output from 3.8 (where the extension works properly)
/ # apk add php7 php7-ssh2
fetch http://dl-cdn.alpinelinux.org/alpine/v3.8/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.8/community/x86_64/APKINDEX.tar.gz
(1/10) Installing php7-common (7.2.13-r0)
(2/10) Installing ncurses-terminfo-base (6.1_p20180818-r1)
(3/10) Installing ncurses-terminfo (6.1_p20180818-r1)
(4/10) Installing ncurses-libs (6.1_p20180818-r1)
(5/10) Installing libedit (20170329.3.1-r3)
(6/10) Installing pcre (8.42-r0)
(7/10) Installing libxml2 (2.9.8-r1)
(8/10) Installing php7 (7.2.13-r0)
(9/10) Installing libssh2 (1.8.0-r3)
(10/10) Installing php7-ssh2 (1.1.2-r2)
Executing busybox-1.28.4-r3.trigger
OK: 19 MiB in 23 packages
/ # php -i | grep -i ssh
Additional .ini files parsed => /etc/php7/conf.d/ssh2.ini
Registered PHP Streams => compress.zlib, php, file, glob, data, http, ftp, ssh2.shell, ssh2.exec, ssh2.tunnel, ssh2.scp, ssh2.sftp
ssh2
SSH2 support => enabled
libssh2 version => 1.8.0
banner => SSH-2.0-libssh2_1.8.0
*(from redmine: issue id 9958, created on 2019-02-03)*
* Relations:
* blocks #99593.9.5Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9961Replace libressl with openssl in initramfs2019-07-23T11:14:54ZCarlo LandmeterReplace libressl with openssl in initramfsCurrently we still pull in libressl even though we have switched to
openssl.
- https://git.alpinelinux.org/mkinitfs/tree/initramfs-init.in\#n44
- https://git.alpinelinux.org/mkinitfs/tree/initramfs-init.in\#n691
*(from redmine: is...Currently we still pull in libressl even though we have switched to
openssl.
- https://git.alpinelinux.org/mkinitfs/tree/initramfs-init.in\#n44
- https://git.alpinelinux.org/mkinitfs/tree/initramfs-init.in\#n691
*(from redmine: issue id 9961, created on 2019-02-05, closed on 2019-03-01)*
* Changesets:
* Revision 17bb28059bbb00e41c2f32227e54e237551b601d by Natanael Copa on 2019-02-26T17:27:11Z:
```
main/mkinitfs: upgrade to 3.4.1
fixes #9961
(cherry picked from commit b5fca7279cf14ae2c843d9649715f71a98b5626b)
```3.9.1Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9962ghostscript: Segfault in GS 9.26 with certain PDFs with -dLastPage=12019-07-26T05:32:45ZMarco Alfanoghostscript: Segfault in GS 9.26 with certain PDFs with -dLastPage=1Descrizione
Segfault in GS 9.26 with certain PDFs with -dLastPage=1
References:
https://bugs.ghostscript.com/show\_bug.cgi?id=700315
Patches:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=fae21f1668d2b44b18b84cf0923a1d...Descrizione
Segfault in GS 9.26 with certain PDFs with -dLastPage=1
References:
https://bugs.ghostscript.com/show\_bug.cgi?id=700315
Patches:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=fae21f1668d2b44b18b84cf0923a1d5f3008a696;hp=2e68cc460dbe349f68b81082ff7344db48eb4820
*(from redmine: issue id 9962, created on 2019-02-06)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9963patch -R : patch: can't remove file 'null': No such file or directory2021-02-06T17:43:26ZLeo Baltuspatch -R : patch: can't remove file 'null': No such file or directoryattached patch when applied creates a new file
patch -p2 &lt;/src/ipxe-77f64b1.embed-retry-dhcp.patch
creating myscript.ipxe
However, when using -R (reverse) it says:
patch -R -p2 &lt;ipxe-77f64b1.embed-retry-dhcp.patch
patching...attached patch when applied creates a new file
patch -p2 </src/ipxe-77f64b1.embed-retry-dhcp.patch
creating myscript.ipxe
However, when using -R (reverse) it says:
patch -R -p2 <ipxe-77f64b1.embed-retry-dhcp.patch
patching file null
patch: can’t open ‘null’: No such file or directory
I expected patch to remove the new file, like gnu-patch does.
*(from redmine: issue id 9963, created on 2019-02-06)*
* Uploads:
* [ipxe-77f64b1.embed-retry-dhcp.patch](/uploads/3fa2fe1b4afc62e72e459fcfd173183c/ipxe-77f64b1.embed-retry-dhcp.patch)https://gitlab.alpinelinux.org/alpine/aports/-/issues/9964Add community/omxplayer aarch64 support2021-11-25T00:08:07ZMarnix RijnartAdd community/omxplayer aarch64 supportNow that Alpine supports aarch64 on Raspberry Pi, it would be nice to
have community/aarch64/omxplayer if that is possible.
*(from redmine: issue id 9964, created on 2019-02-07)*Now that Alpine supports aarch64 on Raspberry Pi, it would be nice to
have community/aarch64/omxplayer if that is possible.
*(from redmine: issue id 9964, created on 2019-02-07)*Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9965mariadb switch to default charset utf8mb42019-07-23T11:14:53ZMarkus Bergholzmariadb switch to default charset utf8mb4Currently mariadb package 10.3 for alpine 3.9 if build with default
charset utf8 and default\_collation utf\_general\_ci
-DDEFAULT_CHARSET=utf8 \
-DDEFAULT_COLLATION=utf8_general_ci \
The utf8 charset is an invalid and broken i...Currently mariadb package 10.3 for alpine 3.9 if build with default
charset utf8 and default\_collation utf\_general\_ci
-DDEFAULT_CHARSET=utf8 \
-DDEFAULT_COLLATION=utf8_general_ci \
The utf8 charset is an invalid and broken implementation made 2003 since
MySQL version 4.1. It was made before today’s UTF-8 standard, RFC 3629.
For compatiblity reasons, the utf8 implementation was kept and the new
correct utf8mb4 implementation was added.
-DDEFAULT_CHARSET=utf8mb4 \
-DDEFAULT_COLLATION=utf8mb4_general_ci \
https://medium.com/@adamhooper/in-mysql-never-use-utf8-use-utf8mb4-11761243e434
*(from redmine: issue id 9965, created on 2019-02-07, closed on 2019-06-19)*3.10.0https://gitlab.alpinelinux.org/alpine/aports/-/issues/9966ip -oneline command broken2020-08-15T07:44:02ZSunny Wuip -oneline command brokenip command using oneline option does not return anything with alpine:3.9
root@ns320983:~# docker run --net br22 --rm -ti --name alpine alpine:3.9 $* sh
/ # cat /etc/alpine-release
3.9.0
/ # ip -oneline link show
/ #...ip command using oneline option does not return anything with alpine:3.9
root@ns320983:~# docker run --net br22 --rm -ti --name alpine alpine:3.9 $* sh
/ # cat /etc/alpine-release
3.9.0
/ # ip -oneline link show
/ #
/ # ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
510: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 02:42:c0:a8:16:86 brd ff:ff:ff:ff:ff:ff
Previous alpine:3.8 is working good.
root@ns320983:~# docker run --net br22 --rm -ti --name alpine alpine:3.8 $* sh
/ # cat /etc/alpine-release
3.8.2
/ # ip -oneline link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000\ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
511: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP \ link/ether 02:42:c0:a8:16:86 brd ff:ff:ff:ff:ff:ff
*(from redmine: issue id 9966, created on 2019-02-07)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/9969APK does not report errors when adding a package to existing virtual package2022-07-30T05:37:46ZChingis SAPK does not report errors when adding a package to existing virtual packageIn the example below I install imagemagick package with the
unsatisfiable constraint (non-existing version), I don’t get any error
when I specify an existing virtual package.
$ docker run --rm -ti alpine:3.9 sh ...In the example below I install imagemagick package with the
unsatisfiable constraint (non-existing version), I don’t get any error
when I specify an existing virtual package.
$ docker run --rm -ti alpine:3.9 sh
/ # apk add --update -t .virtual findutils
fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/x86_64/APKINDEX.tar.gz
(1/2) Installing findutils (4.6.0-r1)
(2/2) Installing .virtual (0)
Executing busybox-1.29.3-r10.trigger
OK: 6 MiB in 16 packages
/ # apk add --update imagemagick=7.0.7.39-r0
ERROR: unsatisfiable constraints:
imagemagick-7.0.8.23-r0:
breaks: world[imagemagick=7.0.7.39-r0]
/ # apk add --update -t .virtual imagemagick=7.0.7.39-r0
OK: 6 MiB in 16 packages
*(from redmine: issue id 9969, created on 2019-02-08)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/9972Package request: glibc2020-03-16T01:56:01ZTheodore DuboisPackage request: glibcMost Linux binary distributions require glibc to run, including many
closed source programs where simply recompiling for musl would be
impossible.
There is already an ABUILD written for this which can be found at
https://github.com/sger...Most Linux binary distributions require glibc to run, including many
closed source programs where simply recompiling for musl would be
impossible.
There is already an ABUILD written for this which can be found at
https://github.com/sgerrand/alpine-pkg-glibc, however it’s only
compatible with x86\_64. If this were in the official repositories, it
would be compatible with every architecture.
*(from redmine: issue id 9972, created on 2019-02-10)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/9975Please activate option MMC_SDHCI_XENON in linux-vanilla on aarch64 architectu...2019-07-23T11:14:50ZKarel KočíPlease activate option MMC_SDHCI_XENON in linux-vanilla on aarch64 architecture to support Turris MOXI am trying to boot Alpinelinux on Turris MOX board and I am missing mmc
driver. It should be enough to enable it as a module.
*(from redmine: issue id 9975, created on 2019-02-10, closed on 2019-05-03)*
* Changesets:
* Revision 7bc...I am trying to boot Alpinelinux on Turris MOX board and I am missing mmc
driver. It should be enough to enable it as a module.
*(from redmine: issue id 9975, created on 2019-02-10, closed on 2019-05-03)*
* Changesets:
* Revision 7bc27d5b738a962db5e34cb43d77173023ab4097 by Natanael Copa on 2019-02-25T08:40:33Z:
```
main/linux-vanilla: enable MMC_SDHCI_XENON for aarch64
fixes #9975
```
* Revision c8f7b24d33210ccc8a63232c75dda8ba02aa13df by Natanael Copa on 2019-02-25T21:22:26Z:
```
main/linux-vanilla: enable MMC_SDHCI_XENON for aarch64
fixes #9975
(cherry picked from commit 7bc27d5b738a962db5e34cb43d77173023ab4097)
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/9976wpa_supplicant: enable support for IBSS RSN (WPA2 in Ad-Hoc mode)2021-08-08T21:14:19ZMarnix Rijnartwpa_supplicant: enable support for IBSS RSN (WPA2 in Ad-Hoc mode)Please add support for IBSS RSN aka WPA2 in Ad-Hoc mode.
Should be as easy as adding CONFIG\_IBSS\_RSN=y to
wpa\_supplicant/config
Sidenote: it does seem that this file is out of date compared to
upstream https://w1.fi/cgit/hostap/plai...Please add support for IBSS RSN aka WPA2 in Ad-Hoc mode.
Should be as easy as adding CONFIG\_IBSS\_RSN=y to
wpa\_supplicant/config
Sidenote: it does seem that this file is out of date compared to
upstream https://w1.fi/cgit/hostap/plain/wpa\_supplicant/defconfig,
which has some more options with comments at the end, including the
requested option.
*(from redmine: issue id 9976, created on 2019-02-10)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9978Allow initramfs search depth to be user-configurable2021-01-09T18:04:01ZChloe KudryavtsevAllow initramfs search depth to be user-configurableCurrently, the initramfs searches for two items:
- A “bootrepo”, identified by a `.boot_repository` file
- An apkovl file, identified as `*.apkovl.tar.gz*`
This is done within `nlplug-findfs`, which recurses into various
coldplugge...Currently, the initramfs searches for two items:
- A “bootrepo”, identified by a `.boot_repository` file
- An apkovl file, identified as `*.apkovl.tar.gz*`
This is done within `nlplug-findfs`, which recurses into various
coldplugged devices.
The depth of the recursion is controlled by
`struct recurseopts.maxdepth`, which is hardcoded to 1 in
`nlplug-findfs.c::893`.
There is also a `find_boot_repositories` function in
`initramfs-init.in::240`, which uses a hardcoded maxdepth of 3.
However, `find_boot_repositories` seems to be more of a fallback, only
being called after relocation, and using `$ALPINE_REPO` if/when
available.
This is fine for the default images, in which `apks` is in the root of
the filesystem, but makes creating custom boot media much more
difficult.
As such, please make the maxdepth configurable, with the initramfs flag
being shared between `nlplug-findfs` and `find_boot_repositories`.
These are the things that would need to be done, from what I can tell:
1. Add a new initramfs-init command line option, e.g “depth”, which
should default to 1 (current value).
2. Use `$KOPT_depth` in `find_boot_repositories`.
3. Add a new int to `struct ueventconf`, e.g “depth”, which should be
of type int, or unsigned int.
4. Add parsing for ‘d’ in `main()` and document it in `usage()`.
5. Set `.maxdepth` to `conf->depth` in `nlplug-findfs.c::893`.
6. Set various invocations of `trigger_path` to use `conf->depth`
instead of a hardcoded `max_depth` when appropriate.
7. Pass `-d $KOPT_depth` to `nlplug-findfs` when appropriate within
`initramfs-init`.
8. Document the changes in `nlplug-findfs.1.in` and
`mkinitfs-bootparam.7.in`.
*(from redmine: issue id 9978, created on 2019-02-12)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9979Alpine doesn't start on Raspberry PI 3 Model B+2021-01-28T23:07:18ZImanuel UlbrichtAlpine doesn't start on Raspberry PI 3 Model B+I try to run my spare Raspberry PI 3 Model B+ with the most recent
version of Alpine Linux (3.9.0). After I plugged everything in, HDMI,
keyboard, LAN, SD Card and power, I don’t get any reaction. After trying
to select the input on my s...I try to run my spare Raspberry PI 3 Model B+ with the most recent
version of Alpine Linux (3.9.0). After I plugged everything in, HDMI,
keyboard, LAN, SD Card and power, I don’t get any reaction. After trying
to select the input on my screen I get no signal and it searches for
other signals. It seems like no HDMI signal is send, and only the red
power LED is on. The activity LED stays off and it doesn’t matter how
long I keep it connected to the power it doesn’t happen anything.
I get the same behavior if I connect the PI to the offical Raspberry PI
touchscreen.
Installing the OS I followed exactly these instructions:
https://wiki.alpinelinux.org/wiki/Classic\_install\_or\_sys\_mode\_on\_Raspberry\_Pi
*(from redmine: issue id 9979, created on 2019-02-13, closed on 2019-02-18)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/9980knock: No IPv6 Support2019-07-23T10:35:02ZPascal Tknock: No IPv6 SupportHello
unfortunately the official knockd project repository\[1\] is rather
dead, and i just ran into the issue that it has no IPv6 support.
This issue in regard to knockd was raised\[2\] already in 2014. There
are forks\[3,4\] that addr...Hello
unfortunately the official knockd project repository\[1\] is rather
dead, and i just ran into the issue that it has no IPv6 support.
This issue in regard to knockd was raised\[2\] already in 2014. There
are forks\[3,4\] that addressed the IPv6 issue.
Would it be possible to either patch the current package or provide a
ipv6 enable package built from one of the forks?
cheers
ptu
\[1\] https://github.com/jvinet/knock
\[2\] https://github.com/jvinet/knock/issues/8
\[3\] https://github.com/Coksnuss/knock
\[4\] https://github.com/TDFKAOlli/knock
*(from redmine: issue id 9980, created on 2019-02-13)*Daniel Isaksendisaksen@alpinelinux.orgDaniel Isaksendisaksen@alpinelinux.orghttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9982/usr/sbin/httpd -DFOREGROUND not working in docker container2019-07-23T11:14:46ZGustav Lennart Voigt/usr/sbin/httpd -DFOREGROUND not working in docker containerHi,
The apache2 httpd package was installed via apk in docker image version
3.9 and latest.
I’ve been trying to execute /usr/sbin/httpd -DFOREGROUND. Unfortunately
this was not working.
So I’ve checked online a little and found on ...Hi,
The apache2 httpd package was installed via apk in docker image version
3.9 and latest.
I’ve been trying to execute /usr/sbin/httpd -DFOREGROUND. Unfortunately
this was not working.
So I’ve checked online a little and found on stackoverflow the following
solution:
mkdir -p /run/apache2
Here is the link to the stackoverflow discussion. It was the last
comment of the entire discussion:
https://stackoverflow.com/questions/53445213/apache-not-starting-in-alpine-image-docker
Maybe this folder can be created by default or as soon as the command is
executed. It would be great because I spend probably 4 to 5 hours to
find out it is this easy to fix.
I can do the commit via pull request myself, just not sure where in the
package I should edit. In APKBUILD or preinstall?
Thank you for the help.
*(from redmine: issue id 9982, created on 2019-02-14, closed on 2019-03-01)*3.9.1Kaarle RitvanenKaarle Ritvanenhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9983Elixir doesn't work anymore in Edge : "dlsym: Resource temporarily unavailable"2021-07-27T14:36:58Zlord lordElixir doesn't work anymore in Edge : "dlsym: Resource temporarily unavailable"After updating/upgrading Alpine, elixir doesn’t work anymore.
Any *mix* commands, even *elixir -v* fail with the error **dlsym:
Resource temporarily unavailable**
I tried downgrading elixir to the latest-stable version (1.7.4) but it
s...After updating/upgrading Alpine, elixir doesn’t work anymore.
Any *mix* commands, even *elixir -v* fail with the error **dlsym:
Resource temporarily unavailable**
I tried downgrading elixir to the latest-stable version (1.7.4) but it
still fail so it’s probably caused by an update in musl or something
else.
*(from redmine: issue id 9983, created on 2019-02-14)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/9984omxplayer key input not working2019-07-23T11:14:45ZMarnix Rijnartomxplayer key input not workingThis is fixed upstream:
https://github.com/popcornmix/omxplayer/commit/9ca45616c6b8a1a9760e9f0b9e21fce7c2d958e3
*(from redmine: issue id 9984, created on 2019-02-14, closed on 2019-06-19)*
* Changesets:
* Revision 2c3b4775831fe68e...This is fixed upstream:
https://github.com/popcornmix/omxplayer/commit/9ca45616c6b8a1a9760e9f0b9e21fce7c2d958e3
*(from redmine: issue id 9984, created on 2019-02-14, closed on 2019-06-19)*
* Changesets:
* Revision 2c3b4775831fe68e2b35f3663ae4310dfcede1f2 by Timo Teräs on 2019-02-15T13:00:59Z:
```
community/omxplayer: upgrade to snapshot of 2019-01-02
fixes #9984
```
* Revision 93d368df56eaf229d71fc6c35319f490d73000ec by Timo Teräs on 2019-02-15T13:02:19Z:
```
community/omxplayer: upgrade to snapshot of 2019-01-02
fixes #9984
```Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9985RethinkDB SSL Errors After Switching Back from LibreSSL to OpenSSL2021-01-06T13:16:42ZJoshua HawnRethinkDB SSL Errors After Switching Back from LibreSSL to OpenSSLThe RethinkDB server which is installed from the *rethinkdb* package on
Alpine 3.9 seems to no longer accept valid client certificates. Here are
logs from one RethinkDB server where another server is trying to open a
TLS connection to it...The RethinkDB server which is installed from the *rethinkdb* package on
Alpine 3.9 seems to no longer accept valid client certificates. Here are
logs from one RethinkDB server where another server is trying to open a
TLS connection to it:
Recursively removing directory /var/data/db/tmp
Initializing directory /var/data/db
Running rethinkdb 2.3.6 (GCC 8.2.0)...
Running on Linux 4.9.125-linuxkit x86_64
Loading data from directory /var/data/db
Listening for intracluster connections on port 29015
Listening for client driver connections on port 28015
Administrative HTTP connections are disabled.
Listening on cluster addresses: 127.0.0.1, 10.0.9.3
Listening on driver addresses: 127.0.0.1, 10.0.9.3
Listening on http addresses: 127.0.0.1, 10.0.9.3
Server ready, "b5cf9533c962_8id" 4739f661-9c4b-4992-aa28-9e81464220e8
error: Cluster server connection TLS handshake failed: sslv3 alert unsupported certificate (OpenSSL error 336151571)
error: Cluster server connection TLS handshake failed: sslv3 alert unsupported certificate (OpenSSL error 336151571)
error: Cluster server connection TLS handshake failed: sslv3 alert unsupported certificate (OpenSSL error 336151571)
error: Cluster server connection TLS handshake failed: sslv3 alert unsupported certificate (OpenSSL error 336151571)
error: Cluster server connection TLS handshake failed: sslv3 alert unsupported certificate (OpenSSL error 336151571)
error: Cluster server connection TLS handshake failed: sslv3 alert unsupported certificate (OpenSSL error 336151571)
Server got SIGTERM from pid 0, uid 0; shutting down...
Shutting down client connections...
All client connections closed.
Shutting down storage engine... (This may take a while if you had a lot of unflushed data in the writeback cache.)
Storage engine shut down.
*(from redmine: issue id 9985, created on 2019-02-15)*Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9986busybox syslog: /sbin/syslogd: unrecognized option: Z2019-07-23T11:14:45ZOleg Titovbusybox syslog: /sbin/syslogd: unrecognized option: ZThe system with Edge produces errors at boot due to BusyBox 1.30.1:
- Starting busybox syslog:
/sbin/syslogd: unrecognized option: Z
and consequently crond could not start also.
*(from redmine: issue id 9986, created on 2019-...The system with Edge produces errors at boot due to BusyBox 1.30.1:
- Starting busybox syslog:
/sbin/syslogd: unrecognized option: Z
and consequently crond could not start also.
*(from redmine: issue id 9986, created on 2019-02-16, closed on 2019-06-19)*
* Changesets:
* Revision 1e0a736522e5301941563c0c1ab623626a6fedad on 2019-02-16T22:21:33Z:
```
main/busybox-initscripts: adjust syslogd timestamp switch
this has now been upstreamed with:
https://git.busybox.net/busybox/commit/sysklogd?id=9d539f9fbd0dc4ea70ed8ba66e3c78150fa8a8b2
fixes: #9986
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/99873.9 postfix + libsasl failures2019-07-23T11:14:43ZAleks Bunin3.9 postfix + libsasl failuresAlpine 3.9 introduced split of `cyrus-sasl` into multiple packages. This
resulted in plugins removed from the `libsasl` package (i.e plain and
login auth were moved into separate packages).
In a container\[1\] I had postfix configured t...Alpine 3.9 introduced split of `cyrus-sasl` into multiple packages. This
resulted in plugins removed from the `libsasl` package (i.e plain and
login auth were moved into separate packages).
In a container\[1\] I had postfix configured to use sasl auth for
upstream smtp server. This worked fine using alpine:3.8. After I
upgraded to alpine:3.9, I started to see errors when attempting to send
message to upstream server, errors were
postfix/smtp[88]: warning: SASL authentication failure: No worthy mechs found
After some research, I figured out that I need to add to packages:
cyrus-sasl-plain and cyrus-sasl-login, but it did not solve the problem.
I was still seeing same error message from postfix and mail won’t go out
to the upstream server.
While browsing the `APKBUILD` file for `cyrus-sasl`, I decided to see
what’s inside it’s config and instead of `cd /etc/sasl2` typed
`mkdir /etc/sasl2` (don’t ask how). Few steps later I sent a test
message and it was delivered. I thought something else helped, but I
re-traced every step and `mkdir /etc/sasl2` was the command which
addressed the problem.
So to sum up: one of the packages `libsasl`, `cyrus-sasl-plain`, or
`cyrus-sasl-login` require presence of the `/etc/sasl2` directory.
\[1\]: https://github.com/sashkab/docker-postfix
*(from redmine: issue id 9987, created on 2019-02-16, closed on 2019-06-19)*
* Changesets:
* Revision 16692f09258dd3fc1719ee5e3dd5be19107cccb1 on 2019-02-16T21:40:52Z:
```
main/cyrus-sasl: add missing /etc/sasl2 to libsasl2
fixes #9987
```
* Revision 8f5360d34adfc86aa743ac5c5bc1818c382ead9b on 2019-02-16T21:44:14Z:
```
main/cyrus-sasl: add missing /etc/sasl2 to libsasl2
fixes #9987
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/9988geoip2 update2019-07-23T11:07:09Zgil bengeoip2 updateHi!
I was wondering if it would be possible to update the geoip package to
use geoip2?
(https://pkgs.alpinelinux.org/package/v3.8/main/x86\_64/geoip)
Geoip is now completely discontinued and you cant even direct download
the old data...Hi!
I was wondering if it would be possible to update the geoip package to
use geoip2?
(https://pkgs.alpinelinux.org/package/v3.8/main/x86\_64/geoip)
Geoip is now completely discontinued and you cant even direct download
the old database.
(https://geolite.maxmind.com/download/geoip/database/GeoIPv6.dat.gz)
Thanks
/gilbn
*(from redmine: issue id 9988, created on 2019-02-17, closed on 2019-05-03)*Leonardo ArenaLeonardo Arenahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9989OCaml 4.07.1 version bump2019-07-26T05:34:06ZAnton KochkovOCaml 4.07.1 version bumpOCaml 4.07 was released with many important fixes:
https://github.com/ocaml/ocaml/releases/tag/4.07.0
The standard library is now packed into a module called Stdlib, which is
open by default. This makes it easier to add new modules to t...OCaml 4.07 was released with many important fixes:
https://github.com/ocaml/ocaml/releases/tag/4.07.0
The standard library is now packed into a module called Stdlib, which is
open by default. This makes it easier to add new modules to the standard
library without clashing with user-defined modules.
The modules Seq (functional iterators) and Float (floating-point
operations) were added to the standard library.
Improvements to several error and warning messages printed by the
compiler make them easier to understand.
Many improvements to flambda. In particular, compilation times are
reduced, as well as the size of the generated .cmx files when using the
-Oclassic optimisation level.
The GC should handle the accumulation of custom blocks in the minor heap
better; this solves some memory-usage issues observed by code which
allocates a lot of small custom blocks, typically small bigarrays.
Removed the dependency on curses/terminfo/termcap.
The HTML manual was restyled and looks nicer.
See https://github.com/ocaml/ocaml/releases/tag/4.07.1 for the bugfix
over 4.07.0
Many distributions already upgraded their OCaml versions:
https://repology.org/metapackage/ocaml/versions
Also note that 4.08.0 release is coming soon
https://github.com/ocaml/ocaml/releases/tag/4.08.0%2Bbeta1 - here is
beta1 already available
*(from redmine: issue id 9989, created on 2019-02-18)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/9990curl: Multiple vulnerabilities (CVE-2018-16890, CVE-2019-3822, CVE-2019-3823)2019-07-23T11:14:42ZAlicha CHcurl: Multiple vulnerabilities (CVE-2018-16890, CVE-2019-3822, CVE-2019-3823)CVE-2018-16890: NTLM type-2 out-of-bounds buffer read
-----------------------------------------------------
The function handling incoming NTLM type-2 messages
(lib/vauth/ntlm.c:ntlm\_decode\_type2\_target) does not validate
incoming da...CVE-2018-16890: NTLM type-2 out-of-bounds buffer read
-----------------------------------------------------
The function handling incoming NTLM type-2 messages
(lib/vauth/ntlm.c:ntlm\_decode\_type2\_target) does not validate
incoming data correctly and is subject to an integer overflow
vulnerability.
Using that overflow, a malicious or broken NTLM server could trick
libcurl to accept a bad length + offset combination that would lead to a
buffer read out-of-bounds.
### Affected versions:
libcurl 7.36.0 to and including 7.63.0
### Not affected versions:
libcurl < 7.36.0 and >= 7.64.0
### References:
https://curl.haxx.se/docs/CVE-2018-16890.html
### Patch:
https://github.com/curl/curl/commit/b780b30d1377adb10bbe774835f49e9b237fb9bb
CVE-2019-3822: NTLMv2 type-3 header stack buffer overflow
---------------------------------------------------------
The function creating an outgoing NTLM type-3 header
(lib/vauth/ntlm.c:Curl\_auth\_create\_ntlm\_type3\_message()), generates
the request HTTP header contents based on previously received data. The
check that exists to prevent the local buffer from getting overflowed is
implemented wrongly (using unsigned math) and as such it does not
prevent the overflow from happening.
This output data can grow larger than the local buffer if very large “nt
response” data is extracted from a previous NTLMv2 header provided by
the malicious or broken HTTP server. Such a “large value” needs to be
around 1000 bytes or more. The actual payload data copied to the target
buffer comes from the NTLMv2 type-2 response header.
### Affected versions:
libcurl 7.36.0 to and including 7.63.0
### Not affected versions:
libcurl < 7.36.0 and >= 7.64.0
### References:
https://curl.haxx.se/docs/CVE-2019-3822.html
### Patch:
https://github.com/curl/curl/commit/86724581b6c
CVE-2019-3823: SMTP end-of-response out-of-bounds read
------------------------------------------------------
If the buffer passed to smtp\_endofresp() isn’t NUL terminated and
contains no character ending the parsed number, and len is set to 5,
then the strtol() call reads beyond the allocated buffer. The read
contents will not be returned to the caller.
### Affected versions:
libcurl 7.34.0 to and including 7.63.0
### Not affected versions:
libcurl < 7.34.0
### References:
https://curl.haxx.se/docs/CVE-2019-3823.html
### Patch:
https://github.com/curl/curl/commit/39df4073e5413fcdbb5a38da0c1ce6f1c0ceb484
*(from redmine: issue id 9990, created on 2019-02-20, closed on 2019-03-05)*
* Relations:
* child #9991
* child #9992
* child #9993
* child #9994Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9991[3.9] curl: Multiple vulnerabilities (CVE-2018-16890, CVE-2019-3822, CVE-2019...2019-07-23T11:14:42ZAlicha CH[3.9] curl: Multiple vulnerabilities (CVE-2018-16890, CVE-2019-3822, CVE-2019-3823)CVE-2018-16890: NTLM type-2 out-of-bounds buffer read
-----------------------------------------------------
The function handling incoming NTLM type-2 messages
(lib/vauth/ntlm.c:ntlm\_decode\_type2\_target) does not validate
incoming da...CVE-2018-16890: NTLM type-2 out-of-bounds buffer read
-----------------------------------------------------
The function handling incoming NTLM type-2 messages
(lib/vauth/ntlm.c:ntlm\_decode\_type2\_target) does not validate
incoming data correctly and is subject to an integer overflow
vulnerability.
Using that overflow, a malicious or broken NTLM server could trick
libcurl to accept a bad length + offset combination that would lead to a
buffer read out-of-bounds.
### Affected versions:
libcurl 7.36.0 to and including 7.63.0
### Not affected versions:
libcurl < 7.36.0 and >= 7.64.0
### References:
https://curl.haxx.se/docs/CVE-2018-16890.html
### Patch:
https://github.com/curl/curl/commit/b780b30d1377adb10bbe774835f49e9b237fb9bb
CVE-2019-3822: NTLMv2 type-3 header stack buffer overflow
---------------------------------------------------------
The function creating an outgoing NTLM type-3 header
(lib/vauth/ntlm.c:Curl\_auth\_create\_ntlm\_type3\_message()), generates
the request HTTP header contents based on previously received data. The
check that exists to prevent the local buffer from getting overflowed is
implemented wrongly (using unsigned math) and as such it does not
prevent the overflow from happening.
This output data can grow larger than the local buffer if very large “nt
response” data is extracted from a previous NTLMv2 header provided by
the malicious or broken HTTP server. Such a “large value” needs to be
around 1000 bytes or more. The actual payload data copied to the target
buffer comes from the NTLMv2 type-2 response header.
### Affected versions:
libcurl 7.36.0 to and including 7.63.0
### Not affected versions:
libcurl < 7.36.0 and >= 7.64.0
### References:
https://curl.haxx.se/docs/CVE-2019-3822.html
### Patch:
https://github.com/curl/curl/commit/86724581b6c
CVE-2019-3823: SMTP end-of-response out-of-bounds read
------------------------------------------------------
If the buffer passed to smtp\_endofresp() isn’t NUL terminated and
contains no character ending the parsed number, and len is set to 5,
then the strtol() call reads beyond the allocated buffer. The read
contents will not be returned to the caller.
### Affected versions:
libcurl 7.34.0 to and including 7.63.0
### Not affected versions:
libcurl < 7.34.0
### References:
https://curl.haxx.se/docs/CVE-2019-3823.html
### Patch:
https://github.com/curl/curl/commit/39df4073e5413fcdbb5a38da0c1ce6f1c0ceb484
*(from redmine: issue id 9991, created on 2019-02-20, closed on 2019-03-05)*
* Relations:
* parent #9990
* Changesets:
* Revision 203cb413da1ecf416412c7b7d53213b1c2b22a09 by Simon F on 2019-02-26T18:17:38Z:
```
main/curl: Security upgrade to 7.64.0
fixes #9991
```3.9.1Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9992[3.8] curl: Multiple vulnerabilities (CVE-2018-16890, CVE-2019-3822, CVE-2019...2019-07-23T11:14:40ZAlicha CH[3.8] curl: Multiple vulnerabilities (CVE-2018-16890, CVE-2019-3822, CVE-2019-3823)CVE-2018-16890: NTLM type-2 out-of-bounds buffer read
-----------------------------------------------------
The function handling incoming NTLM type-2 messages
(lib/vauth/ntlm.c:ntlm\_decode\_type2\_target) does not validate
incoming da...CVE-2018-16890: NTLM type-2 out-of-bounds buffer read
-----------------------------------------------------
The function handling incoming NTLM type-2 messages
(lib/vauth/ntlm.c:ntlm\_decode\_type2\_target) does not validate
incoming data correctly and is subject to an integer overflow
vulnerability.
Using that overflow, a malicious or broken NTLM server could trick
libcurl to accept a bad length + offset combination that would lead to a
buffer read out-of-bounds.
### Affected versions:
libcurl 7.36.0 to and including 7.63.0
### Not affected versions:
libcurl < 7.36.0 and >= 7.64.0
### References:
https://curl.haxx.se/docs/CVE-2018-16890.html
### Patch:
https://github.com/curl/curl/commit/b780b30d1377adb10bbe774835f49e9b237fb9bb
CVE-2019-3822: NTLMv2 type-3 header stack buffer overflow
---------------------------------------------------------
The function creating an outgoing NTLM type-3 header
(lib/vauth/ntlm.c:Curl\_auth\_create\_ntlm\_type3\_message()), generates
the request HTTP header contents based on previously received data. The
check that exists to prevent the local buffer from getting overflowed is
implemented wrongly (using unsigned math) and as such it does not
prevent the overflow from happening.
This output data can grow larger than the local buffer if very large “nt
response” data is extracted from a previous NTLMv2 header provided by
the malicious or broken HTTP server. Such a “large value” needs to be
around 1000 bytes or more. The actual payload data copied to the target
buffer comes from the NTLMv2 type-2 response header.
### Affected versions:
libcurl 7.36.0 to and including 7.63.0
### Not affected versions:
libcurl < 7.36.0 and >= 7.64.0
### References:
https://curl.haxx.se/docs/CVE-2019-3822.html
### Patch:
https://github.com/curl/curl/commit/86724581b6c
CVE-2019-3823: SMTP end-of-response out-of-bounds read
------------------------------------------------------
If the buffer passed to smtp\_endofresp() isn’t NUL terminated and
contains no character ending the parsed number, and len is set to 5,
then the strtol() call reads beyond the allocated buffer. The read
contents will not be returned to the caller.
### Affected versions:
libcurl 7.34.0 to and including 7.63.0
### Not affected versions:
libcurl < 7.34.0
### References:
https://curl.haxx.se/docs/CVE-2019-3823.html
### Patch:
https://github.com/curl/curl/commit/39df4073e5413fcdbb5a38da0c1ce6f1c0ceb484
*(from redmine: issue id 9992, created on 2019-02-20, closed on 2019-03-05)*
* Relations:
* parent #9990
* Changesets:
* Revision 5ba18f0ca5e2e4f2371cf806a531c993d2b9689b on 2019-03-05T08:31:19Z:
```
main/curl: security fixes
CVE-2018-16890, CVE-2019-3822, CVE-2019-3823
Fixes #9992
```3.8.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9993[3.7] curl: Multiple vulnerabilities (CVE-2018-16890, CVE-2019-3822, CVE-2019...2019-07-23T11:14:39ZAlicha CH[3.7] curl: Multiple vulnerabilities (CVE-2018-16890, CVE-2019-3822, CVE-2019-3823)CVE-2018-16890: NTLM type-2 out-of-bounds buffer read
-----------------------------------------------------
The function handling incoming NTLM type-2 messages
(lib/vauth/ntlm.c:ntlm\_decode\_type2\_target) does not validate
incoming da...CVE-2018-16890: NTLM type-2 out-of-bounds buffer read
-----------------------------------------------------
The function handling incoming NTLM type-2 messages
(lib/vauth/ntlm.c:ntlm\_decode\_type2\_target) does not validate
incoming data correctly and is subject to an integer overflow
vulnerability.
Using that overflow, a malicious or broken NTLM server could trick
libcurl to accept a bad length + offset combination that would lead to a
buffer read out-of-bounds.
### Affected versions:
libcurl 7.36.0 to and including 7.63.0
### Not affected versions:
libcurl < 7.36.0 and >= 7.64.0
### References:
https://curl.haxx.se/docs/CVE-2018-16890.html
### Patch:
https://github.com/curl/curl/commit/b780b30d1377adb10bbe774835f49e9b237fb9bb
CVE-2019-3822: NTLMv2 type-3 header stack buffer overflow
---------------------------------------------------------
The function creating an outgoing NTLM type-3 header
(lib/vauth/ntlm.c:Curl\_auth\_create\_ntlm\_type3\_message()), generates
the request HTTP header contents based on previously received data. The
check that exists to prevent the local buffer from getting overflowed is
implemented wrongly (using unsigned math) and as such it does not
prevent the overflow from happening.
This output data can grow larger than the local buffer if very large “nt
response” data is extracted from a previous NTLMv2 header provided by
the malicious or broken HTTP server. Such a “large value” needs to be
around 1000 bytes or more. The actual payload data copied to the target
buffer comes from the NTLMv2 type-2 response header.
### Affected versions:
libcurl 7.36.0 to and including 7.63.0
### Not affected versions:
libcurl < 7.36.0 and >= 7.64.0
### References:
https://curl.haxx.se/docs/CVE-2019-3822.html
### Patch:
https://github.com/curl/curl/commit/86724581b6c
CVE-2019-3823: SMTP end-of-response out-of-bounds read
------------------------------------------------------
If the buffer passed to smtp\_endofresp() isn’t NUL terminated and
contains no character ending the parsed number, and len is set to 5,
then the strtol() call reads beyond the allocated buffer. The read
contents will not be returned to the caller.
### Affected versions:
libcurl 7.34.0 to and including 7.63.0
### Not affected versions:
libcurl < 7.34.0
### References:
https://curl.haxx.se/docs/CVE-2019-3823.html
### Patch:
https://github.com/curl/curl/commit/39df4073e5413fcdbb5a38da0c1ce6f1c0ceb484
*(from redmine: issue id 9993, created on 2019-02-20, closed on 2019-03-05)*
* Relations:
* parent #9990
* Changesets:
* Revision f7cc724b9adaf1c7da74f14c8664294e44e73e99 on 2019-03-05T08:32:08Z:
```
main/curl: security fixes
CVE-2018-16890, CVE-2019-3822, CVE-2019-3823
Fixes #9993
```3.7.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9994[3.6] curl: Multiple vulnerabilities (CVE-2018-16890, CVE-2019-3822, CVE-2019...2021-07-18T07:23:52ZAlicha CH[3.6] curl: Multiple vulnerabilities (CVE-2018-16890, CVE-2019-3822, CVE-2019-3823)CVE-2018-16890: NTLM type-2 out-of-bounds buffer read
-----------------------------------------------------
The function handling incoming NTLM type-2 messages
(lib/vauth/ntlm.c:ntlm\_decode\_type2\_target) does not validate
incoming da...CVE-2018-16890: NTLM type-2 out-of-bounds buffer read
-----------------------------------------------------
The function handling incoming NTLM type-2 messages
(lib/vauth/ntlm.c:ntlm\_decode\_type2\_target) does not validate
incoming data correctly and is subject to an integer overflow
vulnerability.
Using that overflow, a malicious or broken NTLM server could trick
libcurl to accept a bad length + offset combination that would lead to a
buffer read out-of-bounds.
### Affected versions:
libcurl 7.36.0 to and including 7.63.0
### Not affected versions:
libcurl < 7.36.0 and >= 7.64.0
### References:
https://curl.haxx.se/docs/CVE-2018-16890.html
### Patch:
https://github.com/curl/curl/commit/b780b30d1377adb10bbe774835f49e9b237fb9bb
CVE-2019-3822: NTLMv2 type-3 header stack buffer overflow
---------------------------------------------------------
The function creating an outgoing NTLM type-3 header
(lib/vauth/ntlm.c:Curl\_auth\_create\_ntlm\_type3\_message()), generates
the request HTTP header contents based on previously received data. The
check that exists to prevent the local buffer from getting overflowed is
implemented wrongly (using unsigned math) and as such it does not
prevent the overflow from happening.
This output data can grow larger than the local buffer if very large “nt
response” data is extracted from a previous NTLMv2 header provided by
the malicious or broken HTTP server. Such a “large value” needs to be
around 1000 bytes or more. The actual payload data copied to the target
buffer comes from the NTLMv2 type-2 response header.
### Affected versions:
libcurl 7.36.0 to and including 7.63.0
### Not affected versions:
libcurl < 7.36.0 and >= 7.64.0
### References:
https://curl.haxx.se/docs/CVE-2019-3822.html
### Patch:
https://github.com/curl/curl/commit/86724581b6c
CVE-2019-3823: SMTP end-of-response out-of-bounds read
------------------------------------------------------
If the buffer passed to smtp\_endofresp() isn’t NUL terminated and
contains no character ending the parsed number, and len is set to 5,
then the strtol() call reads beyond the allocated buffer. The read
contents will not be returned to the caller.
### Affected versions:
libcurl 7.34.0 to and including 7.63.0
### Not affected versions:
libcurl < 7.34.0
### References:
https://curl.haxx.se/docs/CVE-2019-3823.html
### Patch:
https://github.com/curl/curl/commit/39df4073e5413fcdbb5a38da0c1ce6f1c0ceb484
*(from redmine: issue id 9994, created on 2019-02-20, closed on 2019-03-05)*
* Relations:
* parent #9990
* Changesets:
* Revision d3a946561011a260c6b7a31fa0714a943e38cdfa on 2019-03-05T08:40:08Z:
```
main/curl: security fixes
CVE-2018-16890, CVE-2019-3822, CVE-2019-3823
Fixes #9994
```3.6.3Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9995openssh: Multiple vulnerabilities (CVE-2018-20685, CVE-2019-6109, CVE-2019-6111)2019-07-23T11:14:37ZAlicha CHopenssh: Multiple vulnerabilities (CVE-2018-20685, CVE-2019-6109, CVE-2019-6111)**CVE-2018-20685**: In OpenSSH 7.9, scp.c in the scp client allows
remote SSH servers to bypass intended access restrictions via the
filename of . or an empty filename. The impact is modifying the
permissions of the target directory on...**CVE-2018-20685**: In OpenSSH 7.9, scp.c in the scp client allows
remote SSH servers to bypass intended access restrictions via the
filename of . or an empty filename. The impact is modifying the
permissions of the target directory on the client side.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2018-20685
https://marc.info/?l=oss-security&m=154745764812881&w=2
### Patch:
https://github.com/openssh/openssh-portable/commit/6010c0303a422a9c5fa8860c061bf7105eb7f8b2
**CVE-2019-6109**: An issue was discovered in OpenSSH 7.9. Due to
missing character encoding in the progress display, a malicious server
(or Man-in-The-Middle attacker) can employ crafted object names to
manipulate the client output, e.g., by using ANSI control codes to hide
additional files being transferred. This affects
refresh\_progress\_meter() in progressmeter.c.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2019-6109
https://sintonen.fi/advisories/scp-client-multiple-vulnerabilities.txt
### Patch:
https://github.com/openssh/openssh-portable/commit/8976f1c4b2721c26e878151f52bdf346dfe2d54c
possibly additionally needed:
https://github.com/openssh/openssh-portable/commit/bdc6c63c80b55bcbaa66b5fde31c1cb1d09a41eb
**CVE-2019-6111**: An issue was discovered in OpenSSH 7.9. Due to the
scp implementation being derived from 1983 rcp, the server chooses which
files/directories are sent to the client. However, the scp client only
performs cursory validation of the object name returned (only directory
traversal attacks are prevented). A malicious scp server (or
Man-in-The-Middle attacker) can overwrite arbitrary files in the scp
client target directory. If recursive operation (-r) is performed, the
server can manipulate subdirectories as well (for example, to overwrite
the .ssh/authorized\_keys file).
### References:
https://nvd.nist.gov/vuln/detail/CVE-2019-6111
### Patch:
https://github.com/openssh/openssh-portable/commit/391ffc4b9d31fa1f4ad566499fef9176ff8a07dc
*(from redmine: issue id 9995, created on 2019-02-20, closed on 2019-03-05)*
* Relations:
* child #9996
* child #9997
* child #9998
* child #9999
* child #10000Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9996[3.10] openssh: Multiple vulnerabilities (CVE-2018-20685, CVE-2019-6109, CVE-...2019-07-23T11:14:35ZAlicha CH[3.10] openssh: Multiple vulnerabilities (CVE-2018-20685, CVE-2019-6109, CVE-2019-6111)**CVE-2018-20685**: In OpenSSH 7.9, scp.c in the scp client allows
remote SSH servers to bypass intended access restrictions via the
filename of . or an empty filename. The impact is modifying the
permissions of the target directory on...**CVE-2018-20685**: In OpenSSH 7.9, scp.c in the scp client allows
remote SSH servers to bypass intended access restrictions via the
filename of . or an empty filename. The impact is modifying the
permissions of the target directory on the client side.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2018-20685
https://marc.info/?l=oss-security&m=154745764812881&w=2
### Patch:
https://github.com/openssh/openssh-portable/commit/6010c0303a422a9c5fa8860c061bf7105eb7f8b2
**CVE-2019-6109**: An issue was discovered in OpenSSH 7.9. Due to
missing character encoding in the progress display, a malicious server
(or Man-in-The-Middle attacker) can employ crafted object names to
manipulate the client output, e.g., by using ANSI control codes to hide
additional files being transferred. This affects
refresh\_progress\_meter() in progressmeter.c.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2019-6109
https://sintonen.fi/advisories/scp-client-multiple-vulnerabilities.txt
### Patch:
https://github.com/openssh/openssh-portable/commit/8976f1c4b2721c26e878151f52bdf346dfe2d54c
possibly additionally needed:
https://github.com/openssh/openssh-portable/commit/bdc6c63c80b55bcbaa66b5fde31c1cb1d09a41eb
**CVE-2019-6111**: An issue was discovered in OpenSSH 7.9. Due to the
scp implementation being derived from 1983 rcp, the server chooses which
files/directories are sent to the client. However, the scp client only
performs cursory validation of the object name returned (only directory
traversal attacks are prevented). A malicious scp server (or
Man-in-The-Middle attacker) can overwrite arbitrary files in the scp
client target directory. If recursive operation (-r) is performed, the
server can manipulate subdirectories as well (for example, to overwrite
the .ssh/authorized\_keys file).
### References:
https://nvd.nist.gov/vuln/detail/CVE-2019-6111
### Patch:
https://github.com/openssh/openssh-portable/commit/391ffc4b9d31fa1f4ad566499fef9176ff8a07dc
*(from redmine: issue id 9996, created on 2019-02-20, closed on 2019-03-05)*
* Relations:
* parent #9995
* Changesets:
* Revision 9730fd967a164b246d18cab2dede31af43c83f08 on 2019-03-01T14:30:52Z:
```
main/openssh: security fixes
CVE-2018-20685, CVE-2019-6109, CVE-2019-6111
Rebase HPN patch
Fixes #9996
```
* Revision e231e6bed510c2304f37093f0eadb5708da9728e on 2019-03-04T07:40:56Z:
```
main/openssh: security fixes
CVE-2018-20685, CVE-2019-6109, CVE-2019-6111
Rebase HPN patch
Fixes #9996
```3.10.0Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9997[3.9] openssh: Multiple vulnerabilities (CVE-2018-20685, CVE-2019-6109, CVE-2...2019-07-23T11:14:34ZAlicha CH[3.9] openssh: Multiple vulnerabilities (CVE-2018-20685, CVE-2019-6109, CVE-2019-6111)**CVE-2018-20685**: In OpenSSH 7.9, scp.c in the scp client allows
remote SSH servers to bypass intended access restrictions via the
filename of . or an empty filename. The impact is modifying the
permissions of the target directory on...**CVE-2018-20685**: In OpenSSH 7.9, scp.c in the scp client allows
remote SSH servers to bypass intended access restrictions via the
filename of . or an empty filename. The impact is modifying the
permissions of the target directory on the client side.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2018-20685
https://marc.info/?l=oss-security&m=154745764812881&w=2
### Patch:
https://github.com/openssh/openssh-portable/commit/6010c0303a422a9c5fa8860c061bf7105eb7f8b2
**CVE-2019-6109**: An issue was discovered in OpenSSH 7.9. Due to
missing character encoding in the progress display, a malicious server
(or Man-in-The-Middle attacker) can employ crafted object names to
manipulate the client output, e.g., by using ANSI control codes to hide
additional files being transferred. This affects
refresh\_progress\_meter() in progressmeter.c.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2019-6109
https://sintonen.fi/advisories/scp-client-multiple-vulnerabilities.txt
### Patch:
https://github.com/openssh/openssh-portable/commit/8976f1c4b2721c26e878151f52bdf346dfe2d54c
possibly additionally needed:
https://github.com/openssh/openssh-portable/commit/bdc6c63c80b55bcbaa66b5fde31c1cb1d09a41eb
**CVE-2019-6111**: An issue was discovered in OpenSSH 7.9. Due to the
scp implementation being derived from 1983 rcp, the server chooses which
files/directories are sent to the client. However, the scp client only
performs cursory validation of the object name returned (only directory
traversal attacks are prevented). A malicious scp server (or
Man-in-The-Middle attacker) can overwrite arbitrary files in the scp
client target directory. If recursive operation (-r) is performed, the
server can manipulate subdirectories as well (for example, to overwrite
the .ssh/authorized\_keys file).
### References:
https://nvd.nist.gov/vuln/detail/CVE-2019-6111
### Patch:
https://github.com/openssh/openssh-portable/commit/391ffc4b9d31fa1f4ad566499fef9176ff8a07dc
*(from redmine: issue id 9997, created on 2019-02-20, closed on 2019-03-05)*
* Relations:
* parent #99953.9.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9998[3.8] openssh: Multiple vulnerabilities (CVE-2018-20685, CVE-2019-6109, CVE-2...2019-07-23T11:14:33ZAlicha CH[3.8] openssh: Multiple vulnerabilities (CVE-2018-20685, CVE-2019-6109, CVE-2019-6111)**CVE-2018-20685**: In OpenSSH 7.9, scp.c in the scp client allows
remote SSH servers to bypass intended access restrictions via the
filename of . or an empty filename. The impact is modifying the
permissions of the target directory on...**CVE-2018-20685**: In OpenSSH 7.9, scp.c in the scp client allows
remote SSH servers to bypass intended access restrictions via the
filename of . or an empty filename. The impact is modifying the
permissions of the target directory on the client side.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2018-20685
https://marc.info/?l=oss-security&m=154745764812881&w=2
### Patch:
https://github.com/openssh/openssh-portable/commit/6010c0303a422a9c5fa8860c061bf7105eb7f8b2
**CVE-2019-6109**: An issue was discovered in OpenSSH 7.9. Due to
missing character encoding in the progress display, a malicious server
(or Man-in-The-Middle attacker) can employ crafted object names to
manipulate the client output, e.g., by using ANSI control codes to hide
additional files being transferred. This affects
refresh\_progress\_meter() in progressmeter.c.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2019-6109
https://sintonen.fi/advisories/scp-client-multiple-vulnerabilities.txt
### Patch:
https://github.com/openssh/openssh-portable/commit/8976f1c4b2721c26e878151f52bdf346dfe2d54c
possibly additionally needed:
https://github.com/openssh/openssh-portable/commit/bdc6c63c80b55bcbaa66b5fde31c1cb1d09a41eb
**CVE-2019-6111**: An issue was discovered in OpenSSH 7.9. Due to the
scp implementation being derived from 1983 rcp, the server chooses which
files/directories are sent to the client. However, the scp client only
performs cursory validation of the object name returned (only directory
traversal attacks are prevented). A malicious scp server (or
Man-in-The-Middle attacker) can overwrite arbitrary files in the scp
client target directory. If recursive operation (-r) is performed, the
server can manipulate subdirectories as well (for example, to overwrite
the .ssh/authorized\_keys file).
### References:
https://nvd.nist.gov/vuln/detail/CVE-2019-6111
### Patch:
https://github.com/openssh/openssh-portable/commit/391ffc4b9d31fa1f4ad566499fef9176ff8a07dc
*(from redmine: issue id 9998, created on 2019-02-20, closed on 2019-03-05)*
* Relations:
* parent #9995
* Changesets:
* Revision 6df59aea4486cca6f0c089f72e404ee097b49a02 on 2019-03-04T11:21:06Z:
```
main/openssh: security fixes
CVE-2018-20685, CVE-2019-6109, CVE-2019-6111
Rebase HPN patch
fixes #9998
```3.8.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9999[3.7] openssh: Multiple vulnerabilities (CVE-2018-20685, CVE-2019-6109, CVE-2...2021-07-18T07:23:51ZAlicha CH[3.7] openssh: Multiple vulnerabilities (CVE-2018-20685, CVE-2019-6109, CVE-2019-6111)**CVE-2018-20685**: In OpenSSH 7.9, scp.c in the scp client allows
remote SSH servers to bypass intended access restrictions via the
filename of . or an empty filename. The impact is modifying the
permissions of the target directory on...**CVE-2018-20685**: In OpenSSH 7.9, scp.c in the scp client allows
remote SSH servers to bypass intended access restrictions via the
filename of . or an empty filename. The impact is modifying the
permissions of the target directory on the client side.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2018-20685
https://marc.info/?l=oss-security&m=154745764812881&w=2
### Patch:
https://github.com/openssh/openssh-portable/commit/6010c0303a422a9c5fa8860c061bf7105eb7f8b2
**CVE-2019-6109**: An issue was discovered in OpenSSH 7.9. Due to
missing character encoding in the progress display, a malicious server
(or Man-in-The-Middle attacker) can employ crafted object names to
manipulate the client output, e.g., by using ANSI control codes to hide
additional files being transferred. This affects
refresh\_progress\_meter() in progressmeter.c.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2019-6109
https://sintonen.fi/advisories/scp-client-multiple-vulnerabilities.txt
### Patch:
https://github.com/openssh/openssh-portable/commit/8976f1c4b2721c26e878151f52bdf346dfe2d54c
possibly additionally needed:
https://github.com/openssh/openssh-portable/commit/bdc6c63c80b55bcbaa66b5fde31c1cb1d09a41eb
**CVE-2019-6111**: An issue was discovered in OpenSSH 7.9. Due to the
scp implementation being derived from 1983 rcp, the server chooses which
files/directories are sent to the client. However, the scp client only
performs cursory validation of the object name returned (only directory
traversal attacks are prevented). A malicious scp server (or
Man-in-The-Middle attacker) can overwrite arbitrary files in the scp
client target directory. If recursive operation (-r) is performed, the
server can manipulate subdirectories as well (for example, to overwrite
the .ssh/authorized\_keys file).
### References:
https://nvd.nist.gov/vuln/detail/CVE-2019-6111
### Patch:
https://github.com/openssh/openssh-portable/commit/391ffc4b9d31fa1f4ad566499fef9176ff8a07dc
*(from redmine: issue id 9999, created on 2019-02-20, closed on 2019-03-05)*
* Relations:
* parent #9995
* Changesets:
* Revision cfa04666c50b8dfbe34b6ac8e6b177add54ce649 on 2019-03-04T15:08:29Z:
```
main/openssh: security fixes
CVE-2018-20685, CVE-2019-6109, CVE-2019-6111
Rebased HPN patch, included upstream patch due regression bug due to CVE-2019-6109 fix
Fixes #9999
```3.7.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10000[3.6] openssh: Multiple vulnerabilities (CVE-2018-20685, CVE-2019-6109, CVE-2...2019-07-23T11:14:31ZAlicha CH[3.6] openssh: Multiple vulnerabilities (CVE-2018-20685, CVE-2019-6109, CVE-2019-6111)**CVE-2018-20685**: In OpenSSH 7.9, scp.c in the scp client allows
remote SSH servers to bypass intended access restrictions via the
filename of . or an empty filename. The impact is modifying the
permissions of the target directory on...**CVE-2018-20685**: In OpenSSH 7.9, scp.c in the scp client allows
remote SSH servers to bypass intended access restrictions via the
filename of . or an empty filename. The impact is modifying the
permissions of the target directory on the client side.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2018-20685
https://marc.info/?l=oss-security&m=154745764812881&w=2
### Patch:
https://github.com/openssh/openssh-portable/commit/6010c0303a422a9c5fa8860c061bf7105eb7f8b2
**CVE-2019-6109**: An issue was discovered in OpenSSH 7.9. Due to
missing character encoding in the progress display, a malicious server
(or Man-in-The-Middle attacker) can employ crafted object names to
manipulate the client output, e.g., by using ANSI control codes to hide
additional files being transferred. This affects
refresh\_progress\_meter() in progressmeter.c.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2019-6109
https://sintonen.fi/advisories/scp-client-multiple-vulnerabilities.txt
### Patch:
https://github.com/openssh/openssh-portable/commit/8976f1c4b2721c26e878151f52bdf346dfe2d54c
possibly additionally needed:
https://github.com/openssh/openssh-portable/commit/bdc6c63c80b55bcbaa66b5fde31c1cb1d09a41eb
**CVE-2019-6111**: An issue was discovered in OpenSSH 7.9. Due to the
scp implementation being derived from 1983 rcp, the server chooses which
files/directories are sent to the client. However, the scp client only
performs cursory validation of the object name returned (only directory
traversal attacks are prevented). A malicious scp server (or
Man-in-The-Middle attacker) can overwrite arbitrary files in the scp
client target directory. If recursive operation (-r) is performed, the
server can manipulate subdirectories as well (for example, to overwrite
the .ssh/authorized\_keys file).
### References:
https://nvd.nist.gov/vuln/detail/CVE-2019-6111
### Patch:
https://github.com/openssh/openssh-portable/commit/391ffc4b9d31fa1f4ad566499fef9176ff8a07dc
*(from redmine: issue id 10000, created on 2019-02-20, closed on 2019-03-05)*
* Relations:
* parent #9995
* Changesets:
* Revision 07fc0a9367151053d9b6e8ab68fdb3c7501a4873 on 2019-03-04T15:12:14Z:
```
main/openssh: security fixes
CVE-2018-20685, CVE-2019-6109, CVE-2019-6111
Rebased HPN patch, included upstream patch due regression bug due to CVE-2019-6109 fix
Fixes #10000
```3.6.3Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10001Broken aports ISO build in docker containers2020-06-01T11:21:25ZalgitbotBroken aports ISO build in docker containersCommit 680b40d3d2eebb2a9e83a6d3926f45a2daa58074 in repository git://
git.alpinelinux.org/aports seems to have broken ISO builds with aports
in a
docker container.
I cannot link to build logs or source of what I’m doing as it’s in a ...Commit 680b40d3d2eebb2a9e83a6d3926f45a2daa58074 in repository git://
git.alpinelinux.org/aports seems to have broken ISO builds with aports
in a
docker container.
I cannot link to build logs or source of what I’m doing as it’s in a
private gitlab repository, however I can attach my dockerfile, gitlab
CI
build (basically the commands to run), and the log output (the last two
for
both successful and failing) and whatever else is needed to recreate.
That may not be necessary however - the relevant error I’m getting is:
>>>mkimage-x86\_64: —>kernel x86\_64 vanilla
b010bf8b3d61857350920040dfeb904d5ca48e6b linux-vanilla linux-firmware
wireless-regdb
update-kernel: unrecognized option: modloopfw
Syntax: update-kernel \[-F <feature>\]… \[-p <package>\]… \[\[-a
<arch>\]
<dest_dir>\]
update-kernel -f <flavor> \[-F <feature>\]… \[-p <package>\]… \[-a
<arch>\]
<dest_dir>
update-kernel -b <build_dir> \[-F <feature>\]… \[-p <package>\]…
\[\[-a
<arch>\] <dest_dir>\]
Options: -a|—arch <arch> Install kernel for specified architecture
-b|—build <build_dir> Install custom-built kernel
-f|—flavor <flavor> Install kernel of specified flavor
-F|—feature <feature> Enable initfs feature
-p|—package <package> Additional module or firmware package
-s|—modloopsign Sign modloop with abuild key
-v|—verbose Verbose output
-k|—apk-pubkey <key> Include given key in initramfs
-K|—hostkeys Include host keys in initramfs
-C|—compression Initramfs compression (see mkinitfs for options)
-M|—media Boot media directory layout
—repositories-file <f> apk repositories file
And it appears I am getting that error because on line 6 in
mkimg.base.sh
now uses a flag (—modloopfw) that doesn’t appear to work with
update-kernel when alpine-conf is installed in a docker container.
I’ve added a step to my CI to checkout the git commit before for now,
and
if this does not get fixed may instead revert that commit, but would
rather
see it get fixed properly
Thanks!
—
Jack Hayhurst
*(from redmine: issue id 10001, created on 2019-02-21, closed on 2019-06-19)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/10002py-django: memory exhaustion in django.utils.numberformat.format() (CVE-2019-...2019-07-23T11:14:28ZAlicha CHpy-django: memory exhaustion in django.utils.numberformat.format() (CVE-2019-6975)A vulnerability was found in Django before versions 2.2b1, 2.1.6,
2.0.11, 1.11.19. If django.utils.numberformat.format(), used by
contrib.admin as well as the the floatformat, filesizeformat, and
intcomma templates filters, received a De...A vulnerability was found in Django before versions 2.2b1, 2.1.6,
2.0.11, 1.11.19. If django.utils.numberformat.format(), used by
contrib.admin as well as the the floatformat, filesizeformat, and
intcomma templates filters, received a Decimal with a large number of
digits or a large exponent, it could lead to significant memory usage
due to a call to ‘{:f}’.format(). To avoid this, decimals with more than
200 digits are now formatted using scientific notation.
### References:
https://www.djangoproject.com/weblog/2019/feb/11/security-releases/
https://nvd.nist.gov/vuln/detail/CVE-2019-6975
*(from redmine: issue id 10002, created on 2019-02-21, closed on 2019-03-05)*
* Relations:
* child #10003
* child #10004
* child #10005
* child #10006
* child #10007Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10003[3.10] py-django: memory exhaustion in django.utils.numberformat.format() (CV...2019-07-23T11:14:27ZAlicha CH[3.10] py-django: memory exhaustion in django.utils.numberformat.format() (CVE-2019-6975)A vulnerability was found in Django before versions 2.2b1, 2.1.6,
2.0.11, 1.11.19. If django.utils.numberformat.format(), used by
contrib.admin as well as the the floatformat, filesizeformat, and
intcomma templates filters, received a De...A vulnerability was found in Django before versions 2.2b1, 2.1.6,
2.0.11, 1.11.19. If django.utils.numberformat.format(), used by
contrib.admin as well as the the floatformat, filesizeformat, and
intcomma templates filters, received a Decimal with a large number of
digits or a large exponent, it could lead to significant memory usage
due to a call to ‘{:f}’.format(). To avoid this, decimals with more than
200 digits are now formatted using scientific notation.
### References:
https://www.djangoproject.com/weblog/2019/feb/11/security-releases/
https://nvd.nist.gov/vuln/detail/CVE-2019-6975
*(from redmine: issue id 10003, created on 2019-02-21, closed on 2019-03-05)*
* Relations:
* parent #10002
* Changesets:
* Revision c9aae3180a276eb466bdc57f9863de93b0ed3f4f by Natanael Copa on 2019-02-27T11:25:19Z:
```
main/py-django: security upgrade to 1.11.20 (CVE-2019-6975)
fixes #10003
```3.10.0Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10004[3.9] py-django: memory exhaustion in django.utils.numberformat.format() (CVE...2019-07-23T11:14:26ZAlicha CH[3.9] py-django: memory exhaustion in django.utils.numberformat.format() (CVE-2019-6975)A vulnerability was found in Django before versions 2.2b1, 2.1.6,
2.0.11, 1.11.19. If django.utils.numberformat.format(), used by
contrib.admin as well as the the floatformat, filesizeformat, and
intcomma templates filters, received a De...A vulnerability was found in Django before versions 2.2b1, 2.1.6,
2.0.11, 1.11.19. If django.utils.numberformat.format(), used by
contrib.admin as well as the the floatformat, filesizeformat, and
intcomma templates filters, received a Decimal with a large number of
digits or a large exponent, it could lead to significant memory usage
due to a call to ‘{:f}’.format(). To avoid this, decimals with more than
200 digits are now formatted using scientific notation.
### References:
https://www.djangoproject.com/weblog/2019/feb/11/security-releases/
https://nvd.nist.gov/vuln/detail/CVE-2019-6975
*(from redmine: issue id 10004, created on 2019-02-21, closed on 2019-03-05)*
* Relations:
* parent #10002
* Changesets:
* Revision d955a610fef38bb0404876d8c4122c0931f3ad43 by Natanael Copa on 2019-02-27T11:27:41Z:
```
main/py-django: security upgrade to 1.11.20 (CVE-2019-6975)
fixes #10004
```3.9.1Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10005[3.8] py-django: memory exhaustion in django.utils.numberformat.format() (CVE...2019-07-23T11:14:25ZAlicha CH[3.8] py-django: memory exhaustion in django.utils.numberformat.format() (CVE-2019-6975)A vulnerability was found in Django before versions 2.2b1, 2.1.6,
2.0.11, 1.11.19. If django.utils.numberformat.format(), used by
contrib.admin as well as the the floatformat, filesizeformat, and
intcomma templates filters, received a De...A vulnerability was found in Django before versions 2.2b1, 2.1.6,
2.0.11, 1.11.19. If django.utils.numberformat.format(), used by
contrib.admin as well as the the floatformat, filesizeformat, and
intcomma templates filters, received a Decimal with a large number of
digits or a large exponent, it could lead to significant memory usage
due to a call to ‘{:f}’.format(). To avoid this, decimals with more than
200 digits are now formatted using scientific notation.
### References:
https://www.djangoproject.com/weblog/2019/feb/11/security-releases/
https://nvd.nist.gov/vuln/detail/CVE-2019-6975
*(from redmine: issue id 10005, created on 2019-02-21, closed on 2019-03-05)*
* Relations:
* parent #10002
* Changesets:
* Revision 0bfe3678686189b1417d11fa9e11880a1ddd85c2 on 2019-02-28T14:44:16Z:
```
main/py-django: security upgrade to 1.11.20 (CVE-2019-6975)
Fixes #10005
```3.8.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10006[3.7] py-django: memory exhaustion in django.utils.numberformat.format() (CVE...2019-07-23T11:14:23ZAlicha CH[3.7] py-django: memory exhaustion in django.utils.numberformat.format() (CVE-2019-6975)A vulnerability was found in Django before versions 2.2b1, 2.1.6,
2.0.11, 1.11.19. If django.utils.numberformat.format(), used by
contrib.admin as well as the the floatformat, filesizeformat, and
intcomma templates filters, received a De...A vulnerability was found in Django before versions 2.2b1, 2.1.6,
2.0.11, 1.11.19. If django.utils.numberformat.format(), used by
contrib.admin as well as the the floatformat, filesizeformat, and
intcomma templates filters, received a Decimal with a large number of
digits or a large exponent, it could lead to significant memory usage
due to a call to ‘{:f}’.format(). To avoid this, decimals with more than
200 digits are now formatted using scientific notation.
### References:
https://www.djangoproject.com/weblog/2019/feb/11/security-releases/
https://nvd.nist.gov/vuln/detail/CVE-2019-6975
*(from redmine: issue id 10006, created on 2019-02-21, closed on 2019-03-05)*
* Relations:
* parent #10002
* Changesets:
* Revision e75dee2587e0366d31527c0c11983372be4f532b on 2019-02-28T14:42:28Z:
```
main/py-django: security upgrade to 1.11.20 (CVE-2019-6975)
Fixes #10006
```3.7.2Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10007[3.6] py-django: memory exhaustion in django.utils.numberformat.format() (CVE...2019-07-23T11:14:22ZAlicha CH[3.6] py-django: memory exhaustion in django.utils.numberformat.format() (CVE-2019-6975)A vulnerability was found in Django before versions 2.2b1, 2.1.6,
2.0.11, 1.11.19. If django.utils.numberformat.format(), used by
contrib.admin as well as the the floatformat, filesizeformat, and
intcomma templates filters, received a De...A vulnerability was found in Django before versions 2.2b1, 2.1.6,
2.0.11, 1.11.19. If django.utils.numberformat.format(), used by
contrib.admin as well as the the floatformat, filesizeformat, and
intcomma templates filters, received a Decimal with a large number of
digits or a large exponent, it could lead to significant memory usage
due to a call to ‘{:f}’.format(). To avoid this, decimals with more than
200 digits are now formatted using scientific notation.
### References:
https://www.djangoproject.com/weblog/2019/feb/11/security-releases/
https://nvd.nist.gov/vuln/detail/CVE-2019-6975
*(from redmine: issue id 10007, created on 2019-02-21, closed on 2019-03-05)*
* Relations:
* parent #10002
* Changesets:
* Revision ec414afd222af60156b4bae6021647de7b032675 on 2019-02-28T14:40:04Z:
```
main/py-django: security upgrade to 1.11.20 (CVE-2019-6975)
Fixes #10007
```3.6.3Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10008nasm: Multiple vulnerabilities (CVE-2019-6290, CVE-2019-6291)2020-05-03T19:22:02ZAlicha CHnasm: Multiple vulnerabilities (CVE-2019-6290, CVE-2019-6291)**CVE-2019-6290**: An infinite recursion issue was discovered in eval.c
in Netwide Assembler (NASM) through 2.14.02. There is a stack exhaustion
problem resulting from infinite recursion in the functions expr, rexp,
bexpr and cexpr in ce...**CVE-2019-6290**: An infinite recursion issue was discovered in eval.c
in Netwide Assembler (NASM) through 2.14.02. There is a stack exhaustion
problem resulting from infinite recursion in the functions expr, rexp,
bexpr and cexpr in certain scenarios involving lots of ‘{’ characters.
Remote attackers could leverage this vulnerability to cause a
denial-of-service via a crafted asm file.
### References:
https://bugzilla.nasm.us/show\_bug.cgi?id=3392548
https://nvd.nist.gov/vuln/detail/CVE-2019-6290
**CVE-2019-6291**: An issue was discovered in the function expr6 in
eval.c in Netwide Assembler (NASM) through 2.14.02. There is a stack
exhaustion problem caused by the expr6 function making recursive calls
to itself in certain scenarios involving lots of ‘!’ or ‘+’ or ‘-’
characters. Remote attackers could leverage this vulnerability to cause
a denial-of-service via a crafted asm file.
### References:
https://bugzilla.nasm.us/show\_bug.cgi?id=3392549
https://nvd.nist.gov/vuln/detail/CVE-2019-6291
*(from redmine: issue id 10008, created on 2019-02-21)*
* Relations:
* child #10009
* child #10010
* child #10011
* child #10012
* child #10013Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10009[3.10] nasm: Multiple vulnerabilities (CVE-2019-6290, CVE-2019-6291)2020-12-11T03:34:06ZAlicha CH[3.10] nasm: Multiple vulnerabilities (CVE-2019-6290, CVE-2019-6291)**CVE-2019-6290**: An infinite recursion issue was discovered in eval.c
in Netwide Assembler (NASM) through 2.14.02. There is a stack exhaustion
problem resulting from infinite recursion in the functions expr, rexp,
bexpr and cexpr in ce...**CVE-2019-6290**: An infinite recursion issue was discovered in eval.c
in Netwide Assembler (NASM) through 2.14.02. There is a stack exhaustion
problem resulting from infinite recursion in the functions expr, rexp,
bexpr and cexpr in certain scenarios involving lots of ‘{’ characters.
Remote attackers could leverage this vulnerability to cause a
denial-of-service via a crafted asm file.
### References:
https://bugzilla.nasm.us/show_bug.cgi?id=3392548
https://nvd.nist.gov/vuln/detail/CVE-2019-6290
**CVE-2019-6291**: An issue was discovered in the function expr6 in
eval.c in Netwide Assembler (NASM) through 2.14.02. There is a stack
exhaustion problem caused by the expr6 function making recursive calls
to itself in certain scenarios involving lots of ‘!’ or ‘+’ or ‘-’
characters. Remote attackers could leverage this vulnerability to cause
a denial-of-service via a crafted asm file.
### References:
https://bugzilla.nasm.us/show_bug.cgi?id=3392549
https://nvd.nist.gov/vuln/detail/CVE-2019-6291
*(from redmine: issue id 10009, created on 2019-02-21)*
* Relations:
* parent #100083.10.6Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10010[3.9] nasm: Multiple vulnerabilities (CVE-2019-6290, CVE-2019-6291)2021-07-18T07:23:52ZAlicha CH[3.9] nasm: Multiple vulnerabilities (CVE-2019-6290, CVE-2019-6291)**CVE-2019-6290**: An infinite recursion issue was discovered in eval.c
in Netwide Assembler (NASM) through 2.14.02. There is a stack exhaustion
problem resulting from infinite recursion in the functions expr, rexp,
bexpr and cexpr in ce...**CVE-2019-6290**: An infinite recursion issue was discovered in eval.c
in Netwide Assembler (NASM) through 2.14.02. There is a stack exhaustion
problem resulting from infinite recursion in the functions expr, rexp,
bexpr and cexpr in certain scenarios involving lots of ‘{’ characters.
Remote attackers could leverage this vulnerability to cause a
denial-of-service via a crafted asm file.
### References:
https://bugzilla.nasm.us/show\_bug.cgi?id=3392548
https://nvd.nist.gov/vuln/detail/CVE-2019-6290
**CVE-2019-6291**: An issue was discovered in the function expr6 in
eval.c in Netwide Assembler (NASM) through 2.14.02. There is a stack
exhaustion problem caused by the expr6 function making recursive calls
to itself in certain scenarios involving lots of ‘!’ or ‘+’ or ‘-’
characters. Remote attackers could leverage this vulnerability to cause
a denial-of-service via a crafted asm file.
### References:
https://bugzilla.nasm.us/show\_bug.cgi?id=3392549
https://nvd.nist.gov/vuln/detail/CVE-2019-6291
*(from redmine: issue id 10010, created on 2019-02-21)*
* Relations:
* parent #100083.9.7Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10014polkit: Temporary auth hijacking via PID reuse and non-atomic fork (CVE-2019-...2019-07-23T10:32:36ZAlicha CHpolkit: Temporary auth hijacking via PID reuse and non-atomic fork (CVE-2019-6133)In PolicyKit (aka polkit) 0.115, the “start time” protection mechanism
can be bypassed because fork() is not atomic, and therefore
authorization
decisions are improperly cached. This is related to lack of uid checking
in polkitbackend/...In PolicyKit (aka polkit) 0.115, the “start time” protection mechanism
can be bypassed because fork() is not atomic, and therefore
authorization
decisions are improperly cached. This is related to lack of uid checking
in polkitbackend/polkitbackendinteractiveauthority.c.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2019-6133
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6133
### Patch:
https://gitlab.freedesktop.org/polkit/polkit/commit/c898fdf4b1aafaa04f8ada9d73d77c8bb76e2f81
*(from redmine: issue id 10014, created on 2019-02-21)*
* Relations:
* child #10015
* child #10016
* child #10017
* child #10018
* child #10019LeoLeohttps://gitlab.alpinelinux.org/alpine/aports/-/issues/10016[3.9] polkit: Temporary auth hijacking via PID reuse and non-atomic fork (CVE...2019-12-23T11:54:22ZAlicha CH[3.9] polkit: Temporary auth hijacking via PID reuse and non-atomic fork (CVE-2019-6133)In PolicyKit (aka polkit) 0.115, the “start time” protection mechanism
can be bypassed because fork() is not atomic, and therefore
authorization
decisions are improperly cached. This is related to lack of uid checking
in polkitbackend/...In PolicyKit (aka polkit) 0.115, the “start time” protection mechanism
can be bypassed because fork() is not atomic, and therefore
authorization
decisions are improperly cached. This is related to lack of uid checking
in polkitbackend/polkitbackendinteractiveauthority.c.
### References:
https://nvd.nist.gov/vuln/detail/CVE-2019-6133
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6133
### Patch:
https://gitlab.freedesktop.org/polkit/polkit/commit/c898fdf4b1aafaa04f8ada9d73d77c8bb76e2f81
*(from redmine: issue id 10016, created on 2019-02-21)*
* Relations:
* parent #100143.9.5Rasmus Thomsenoss@cogitri.devRasmus Thomsenoss@cogitri.dev