alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2024-03-06T20:35:03Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4514texlive isn't compiling .tex files2024-03-06T20:35:03Zalgitbottexlive isn't compiling .tex filesI did ‘apk add texlive@testing’ and it installed correctly.
Then I tried to compile a .tex file with ‘pdftex’ (first note: shouldn’t
it be pdflatex? that’s what I had in other distros)
However, it didn’t work.
This is pdfTeX, Versio...I did ‘apk add texlive@testing’ and it installed correctly.
Then I tried to compile a .tex file with ‘pdftex’ (first note: shouldn’t
it be pdflatex? that’s what I had in other distros)
However, it didn’t work.
This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015)
(preloaded format=pdftex)
restricted \\write18 enabled.
kpathsea: Running mktexfmt pdftex.fmt
Can’t locate mktexlsr.pl in `INC (`INC contains: //tlpkg
//texmf-dist/scripts/texlive /usr/local/lib/perl5/site\_perl
/usr/local/share/perl5/site\_perl /usr/lib/perl5/vendor\_perl
/usr/share/perl5/vendor\_perl /usr/lib/perl5/core\_perl
/usr/share/perl5/core\_perl .) at /usr/bin/mktexfmt line 24.
BEGIN failed—compilation aborted at /usr/bin/mktexfmt line 26.
I can’t find the format file \`pdftex.fmt’!
Thank you.
*(from redmine: issue id 4514, created on 2015-08-07)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/4513bind-9.10.2_p3-r0 does not work in a docker2019-07-23T13:49:38ZMaxim Kostrikinbind-9.10.2_p3-r0 does not work in a dockerdocker run -it alpine sh
Unable to find image ‘alpine:latest’ locally
latest: Pulling from alpine
31f630c65071: Already exists
alpine:latest: The image you are pulling has been verified. Important:
image verification is a tech pr...docker run -it alpine sh
Unable to find image ‘alpine:latest’ locally
latest: Pulling from alpine
31f630c65071: Already exists
alpine:latest: The image you are pulling has been verified. Important:
image verification is a tech preview feature and should not be relied on
to provide security.
Digest:
sha256:c471fce1d08618adf4c6c0d72c047b9f3d5ef82cae0ca9a157ce1c800d42722f
Status: Downloaded newer image for alpine:latest
/ \# apk update
fetch
http://dl-4.alpinelinux.org/alpine/v3.2/main/x86\_64/APKINDEX.tar.gz
v3.2.2-57-g329b21b \[http://dl-4.alpinelinux.org/alpine/v3.2/main\]
OK: 5288 distinct packages available
/ \# apk add bind
(1/3) Installing libgcc (4.9.2-r5)
(2/3) Installing bind-libs (9.10.2\_p3-r0)
(3/3) Installing bind (9.10.2\_p3-r0)
Executing bind-9.10.2\_p3-r0.pre-install
Executing busybox-1.23.2-r0.trigger
OK: 9 MiB in 18 packages
/ \# named -g
named: syscall(capset) failed: Operation not permitted: please ensure
that the capset kernel module is loaded. see insmod(8)
Previous version works fine.
*(from redmine: issue id 4513, created on 2015-08-06, closed on 2015-08-13)*
* Relations:
* relates #4281
* Changesets:
* Revision 7e7e91cb98d2ba8a3d1a9bb048323248867ad76b by Natanael Copa on 2015-08-13T12:11:34Z:
```
main/bind: user libcap for capabilities
fixes #4513
(cherry picked from commit c5b5874d381e9242763731fea6174f3040f7cdf4)
```3.2.3https://gitlab.alpinelinux.org/alpine/aports/-/issues/4512python: ctypes.util.find_library() does not work (regresion of bug #2012)2019-07-23T13:38:32ZBernardo Cabezas Serrapython: ctypes.util.find_library() does not work (regresion of bug #2012)Seems a regresion of bug \#2012, for alpine versions >2.7.
It seems related to python ctypes.util.find\_library() implementation,
based on **ldconfig -p 2**.
On alpine < 3.1, \*ldconfig -p 2 worked ok:
/ # ldconfig -p 2
3...Seems a regresion of bug \#2012, for alpine versions >2.7.
It seems related to python ctypes.util.find\_library() implementation,
based on **ldconfig -p 2**.
On alpine < 3.1, \*ldconfig -p 2 worked ok:
/ # ldconfig -p 2
32 libs found in cache `/etc/ld.so.cache' (version 1.7.0)
libz.so.1 (ELF) => /lib/libz.so.1
libutil.so.0.9.32 (ELF) => /lib/libutil.so.0.9.32
libubacktrace.so.0.9.32 (ELF) => /lib/libubacktrace.so.0.9.32
libssl.so.1.0.0 (ELF) => /lib/libssl.so.1.0.0
libssl.so.1.0.0 (ELF) => /usr/lib/libssl.so.1.0.0
libsqlite3.so.0 (ELF) => /usr/lib/libsqlite3.so.0
libsqlite3.so (ELF) => /usr/lib/libsqlite3.so
librt.so.0.9.32 (ELF) => /lib/librt.so.0.9.32
libresolv.so.0.9.32 (ELF) => /lib/libresolv.so.0.9.32
libreadline.so.6 (ELF) => /usr/lib/libreadline.so.6
librc.so.1 (ELF) => /lib/librc.so.1
libpython2.7.so.1.0 (ELF) => /usr/lib/libpython2.7.so.1.0
libpthread.so.0.9.32 (ELF) => /lib/libpthread.so.0.9.32
libpanel.so.5 (ELF) => /usr/lib/libpanel.so.5
libncurses.so.5 (ELF) => /usr/lib/libncurses.so.5
libmenu.so.5 (ELF) => /usr/lib/libmenu.so.5
libm.so.0.9.32 (ELF) => /lib/libm.so.0.9.32
libhistory.so.6 (ELF) => /usr/lib/libhistory.so.6
libgdbm_compat.so.4 (ELF) => /usr/lib/libgdbm_compat.so.4
libgdbm.so.4 (ELF) => /usr/lib/libgdbm.so.4
libgcc_s.so.1 (ELF) => /usr/lib/libgcc_s.so.1
libform.so.5 (ELF) => /usr/lib/libform.so.5
libffi.so.6 (ELF) => /usr/lib/libffi.so.6
libexpat.so.1 (ELF) => /usr/lib/libexpat.so.1
libeinfo.so.1 (ELF) => /lib/libeinfo.so.1
libdl.so.0.9.32 (ELF) => /lib/libdl.so.0.9.32
libcrypto.so.1.0.0 (ELF) => /lib/libcrypto.so.1.0.0
libcrypto.so.1.0.0 (ELF) => /usr/lib/libcrypto.so.1.0.0
libcrypt.so.0.9.32 (ELF) => /lib/libcrypt.so.0.9.32
libc.so.0.9.32 (ELF) => /lib/libc.so.0.9.32
libbz2.so.1 (ELF) => /usr/lib/libbz2.so.1
ld64-uClibc.so.0.9.32 (ELF) => /lib/ld64-uClibc.so.0.9.32
But fails on alpine >3.1:
/app # ldconfig -p 2
Illegal option -p
Way to reproduce:
-----------------
Test ctypes.util.find\_library() on alpine versions under docker:
- works on 2.6, 2.7
docker run --rm -ti alpine:2.6 sh -c "apk update && apk add python && python -c 'from ctypes.util import find_library;print find_library(\"c\")'"
[...]
libc.so.0.9.32
docker run --rm -ti alpine:2.7 sh -c "apk update && apk add python && python -c 'from ctypes.util import find_library;print find_library(\"c\")'"
[...]
libc.so.0.9.32
<!-- -->
- does not work on 3.1, 3.2:
docker run --rm -ti alpine:3.1 sh -c "apk update && apk add python && python -c 'from ctypes.util import find_library;print find_library(\"c\")'"
[...]
None
*(from redmine: issue id 4512, created on 2015-08-06, closed on 2015-08-13)*
* Relations:
* relates #5038
* relates #5264
* Changesets:
* Revision 837f731a38d0a2c1c20c6a4f86cd5368ff02a23b by Natanael Copa on 2015-08-11T09:19:42Z:
```
main/python: fix find_library with musl
ref #4512
```
* Revision 78e9529bfe15f2cff42b4e124ebfb82c5707669d by Natanael Copa on 2015-08-13T12:26:50Z:
```
main/python: fix find_library with musl
fixes #4512
(cherry picked from commit 837f731a38d0a2c1c20c6a4f86cd5368ff02a23b)
```
* Revision 2bdc331e7a3d4b4f4d4d0fa7b384e2970d892178 by Natanael Copa on 2016-06-29T09:20:45Z:
```
main/python: fix find_library with musl
fixes #4512
(cherry picked from commit 78e9529bfe15f2cff42b4e124ebfb82c5707669d)
Conflicts:
main/python/APKBUILD
```3.2.3Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4511freeradius: rest module compiled without json support2019-07-23T13:49:41ZMichael Melnykfreeradius: rest module compiled without json supportReviewed \#4449 - works fine, but json format is not supported by
rlm\_rest.
To enable this feature, build process requires “json-c-dev” package.
Dependency on “json-c” package.
*(from redmine: issue id 4511, created on 2015-08-05,...Reviewed \#4449 - works fine, but json format is not supported by
rlm\_rest.
To enable this feature, build process requires “json-c-dev” package.
Dependency on “json-c” package.
*(from redmine: issue id 4511, created on 2015-08-05, closed on 2015-08-13)*
* Relations:
* relates #4449
* Changesets:
* Revision 8be40b15b63d279a0f1ce78e612e1f407dffcbe6 by Natanael Copa on 2015-08-06T12:04:36Z:
```
main/freeradius: add json support to rest module
it needs an ugly hack to find the header
ref #4511
```
* Revision da270ce2218b1c5d396f7a92d36c462192481c60 by Natanael Copa on 2015-08-11T10:08:26Z:
```
main/freeradius: add json support to rest module
it needs an ugly hack to find the header
fixes #4511
(cherry picked from commit 8be40b15b63d279a0f1ce78e612e1f407dffcbe6)
```3.2.3https://gitlab.alpinelinux.org/alpine/aports/-/issues/4510eudev from edge breaks diskless mode2019-07-15T14:23:01ZAugust Kleineudev from edge breaks diskless modeSteps to reproduce:
1. Upgrade to edge in /etc/apk/repositories
2. apk del udev
3. apk add eudev
4. Run setup-udev. It says:
>“Udev requires /dev to be a mounted devtmpfs.
>Please reconfigure your system.
>ERROR: u...Steps to reproduce:
1. Upgrade to edge in /etc/apk/repositories
2. apk del udev
3. apk add eudev
4. Run setup-udev. It says:
>“Udev requires /dev to be a mounted devtmpfs.
>Please reconfigure your system.
>ERROR: udev failed to start”
If you do *“mount -n -t devtmpfs dev /dev”* udev is able to start but
when reboot
it fails again (I am previously running *“lbu ci”* , of course).
Also the trick: *“ln -s /dev/null
/etc/udev/rules.d/80-net-name-slot.rules”* does not work
on diskless mode (it works in a traditional hard-disk install) because
it does not survive
across reboots. (again using *“lbu ci”*)
*(from redmine: issue id 4510, created on 2015-08-04)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4509[v3.2] bind: DNS query issues (CVE-2015-4620, CVE-2015-5477)2019-07-23T13:49:41ZAlexander Belous[v3.2] bind: DNS query issues (CVE-2015-4620, CVE-2015-5477)**CVE-2015-4620**
>An attacker who can cause a validating resolver to query a zone
containing specifically constructed contents can cause that resolver to
fail an assertion and terminate due to a defect in validation code.
>
>Version...**CVE-2015-4620**
>An attacker who can cause a validating resolver to query a zone
containing specifically constructed contents can cause that resolver to
fail an assertion and terminate due to a defect in validation code.
>
>Versions affected: BIND 9.7.1 ->9.7.7, 9.8.0 ->9.8.8, 9.9.0
->9.9.7, 9.10.0 ->9.10.2-P1.
>
>A very uncommon combination of zone data has been found that
triggers a bug in BIND, with the result that named will exit with a
“REQUIRE” failure in name.c when validating the data returned in answer
to a recursive query.
>
>This means that a recursive resolver that is performing DNSSEC
validation can be deliberately stopped by an attacker who can cause the
resolver to perform a query against a maliciously-constructed zone.
>
>Impact:
>
>A recursive resolver that is performing DNSSEC validation can be
deliberately terminated by any attacker who can cause a query to be
performed against a maliciously constructed zone. This will result in a
denial of service to clients who rely on that resolver.
>
>DNSSEC validation is only performed by a recursive resolver if it
has “dnssec-validation auto;” in its configuration or if it has a root
trust anchor defined and has “dnssec-validation yes;” set (either by
accepting the default or via an explicitly set value of “yes”.) By
default ISC BIND recursive servers will not validate. (However, ISC
defaults may have been changed by your distributor.)
**CVE-2015-5477**
>TKEY query handling flaw leading to denial of service
>
>
>Versions affected: BIND 9.x before 9.9.7-P2 and 9.10.x before
9.10.2-P3
>
>Details
>
>A flaw was found in the way BIND handled requests for TKEY DNS
resource records. A remote attacker could use this flaw to make named
(functioning as an authoritative DNS server or a DNS resolver) exit
unexpectedly with an assertion failure via a specially crafted DNS
request packet.
Reference:
https://kb.isc.org/article/AA-01267
https://access.redhat.com/security/cve/CVE-2015-5477
*(from redmine: issue id 4509, created on 2015-08-03, closed on 2015-08-05)*
* Relations:
* parent #4505
* Changesets:
* Revision 5a6eb2946c459470eb1ee36aca054c7440dff5f9 by Natanael Copa on 2015-08-04T09:49:17Z:
```
main/bind: security upgrade to 9.10.2_p3 (CVE-2015-4620,CVE-2015-5477)
fixes #4509
```3.2.3Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4508[v3.1] bind: DNS query issues (CVE-2015-4620, CVE-2015-5477)2019-07-23T13:49:43ZAlexander Belous[v3.1] bind: DNS query issues (CVE-2015-4620, CVE-2015-5477)**CVE-2015-4620**
>An attacker who can cause a validating resolver to query a zone
containing specifically constructed contents can cause that resolver to
fail an assertion and terminate due to a defect in validation code.
>
>Version...**CVE-2015-4620**
>An attacker who can cause a validating resolver to query a zone
containing specifically constructed contents can cause that resolver to
fail an assertion and terminate due to a defect in validation code.
>
>Versions affected: BIND 9.7.1 ->9.7.7, 9.8.0 ->9.8.8, 9.9.0
->9.9.7, 9.10.0 ->9.10.2-P1.
>
>A very uncommon combination of zone data has been found that
triggers a bug in BIND, with the result that named will exit with a
“REQUIRE” failure in name.c when validating the data returned in answer
to a recursive query.
>
>This means that a recursive resolver that is performing DNSSEC
validation can be deliberately stopped by an attacker who can cause the
resolver to perform a query against a maliciously-constructed zone.
>
>Impact:
>
>A recursive resolver that is performing DNSSEC validation can be
deliberately terminated by any attacker who can cause a query to be
performed against a maliciously constructed zone. This will result in a
denial of service to clients who rely on that resolver.
>
>DNSSEC validation is only performed by a recursive resolver if it
has “dnssec-validation auto;” in its configuration or if it has a root
trust anchor defined and has “dnssec-validation yes;” set (either by
accepting the default or via an explicitly set value of “yes”.) By
default ISC BIND recursive servers will not validate. (However, ISC
defaults may have been changed by your distributor.)
**CVE-2015-5477**
>TKEY query handling flaw leading to denial of service
>
>
>Versions affected: BIND 9.x before 9.9.7-P2 and 9.10.x before
9.10.2-P3
>
>Details
>
>A flaw was found in the way BIND handled requests for TKEY DNS
resource records. A remote attacker could use this flaw to make named
(functioning as an authoritative DNS server or a DNS resolver) exit
unexpectedly with an assertion failure via a specially crafted DNS
request packet.
Reference:
https://kb.isc.org/article/AA-01267
https://access.redhat.com/security/cve/CVE-2015-5477
*(from redmine: issue id 4508, created on 2015-08-03, closed on 2015-08-05)*
* Relations:
* parent #4505
* Changesets:
* Revision 04d850a4688fbc93cc8bee5266eda1a0420639c8 by Natanael Copa on 2015-08-04T11:58:58Z:
```
main/bind: security upgrade to 9.10.2_p3 (CVE-2015-4620,CVE-2015-5477)
fixes #4508
```3.1.5Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4507[v3.0] bind: DNS query issues (CVE-2015-4620, CVE-2015-5477)2019-07-23T13:49:44ZAlexander Belous[v3.0] bind: DNS query issues (CVE-2015-4620, CVE-2015-5477)**CVE-2015-4620**
>An attacker who can cause a validating resolver to query a zone
containing specifically constructed contents can cause that resolver to
fail an assertion and terminate due to a defect in validation code.
>
>Version...**CVE-2015-4620**
>An attacker who can cause a validating resolver to query a zone
containing specifically constructed contents can cause that resolver to
fail an assertion and terminate due to a defect in validation code.
>
>Versions affected: BIND 9.7.1 ->9.7.7, 9.8.0 ->9.8.8, 9.9.0
->9.9.7, 9.10.0 ->9.10.2-P1.
>
>A very uncommon combination of zone data has been found that
triggers a bug in BIND, with the result that named will exit with a
“REQUIRE” failure in name.c when validating the data returned in answer
to a recursive query.
>
>This means that a recursive resolver that is performing DNSSEC
validation can be deliberately stopped by an attacker who can cause the
resolver to perform a query against a maliciously-constructed zone.
>
>Impact:
>
>A recursive resolver that is performing DNSSEC validation can be
deliberately terminated by any attacker who can cause a query to be
performed against a maliciously constructed zone. This will result in a
denial of service to clients who rely on that resolver.
>
>DNSSEC validation is only performed by a recursive resolver if it
has “dnssec-validation auto;” in its configuration or if it has a root
trust anchor defined and has “dnssec-validation yes;” set (either by
accepting the default or via an explicitly set value of “yes”.) By
default ISC BIND recursive servers will not validate. (However, ISC
defaults may have been changed by your distributor.)
**CVE-2015-5477**
>TKEY query handling flaw leading to denial of service
>
>
>Versions affected: BIND 9.x before 9.9.7-P2 and 9.10.x before
9.10.2-P3
>
>Details
>
>A flaw was found in the way BIND handled requests for TKEY DNS
resource records. A remote attacker could use this flaw to make named
(functioning as an authoritative DNS server or a DNS resolver) exit
unexpectedly with an assertion failure via a specially crafted DNS
request packet.
Reference:
https://kb.isc.org/article/AA-01267
https://access.redhat.com/security/cve/CVE-2015-5477
*(from redmine: issue id 4507, created on 2015-08-03, closed on 2015-08-05)*
* Relations:
* parent #4505
* Changesets:
* Revision 9e4e4422f4ff9de99661a5932d2266508a6d98ac by Natanael Copa on 2015-08-04T12:02:58Z:
```
main/bind: security upgrade to 9.10.2_p3 (CVE-2015-4620,CVE-2015-5477)
fixes #4507
```3.0.7Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4506[v2.7] bind: DNS query issues (CVE-2015-4620, CVE-2015-5477)2019-07-23T13:49:45ZAlexander Belous[v2.7] bind: DNS query issues (CVE-2015-4620, CVE-2015-5477)**CVE-2015-4620**
>An attacker who can cause a validating resolver to query a zone
containing specifically constructed contents can cause that resolver to
fail an assertion and terminate due to a defect in validation code.
>
>Version...**CVE-2015-4620**
>An attacker who can cause a validating resolver to query a zone
containing specifically constructed contents can cause that resolver to
fail an assertion and terminate due to a defect in validation code.
>
>Versions affected: BIND 9.7.1 ->9.7.7, 9.8.0 ->9.8.8, 9.9.0
->9.9.7, 9.10.0 ->9.10.2-P1.
>
>A very uncommon combination of zone data has been found that
triggers a bug in BIND, with the result that named will exit with a
“REQUIRE” failure in name.c when validating the data returned in answer
to a recursive query.
>
>This means that a recursive resolver that is performing DNSSEC
validation can be deliberately stopped by an attacker who can cause the
resolver to perform a query against a maliciously-constructed zone.
>
>Impact:
>
>A recursive resolver that is performing DNSSEC validation can be
deliberately terminated by any attacker who can cause a query to be
performed against a maliciously constructed zone. This will result in a
denial of service to clients who rely on that resolver.
>
>DNSSEC validation is only performed by a recursive resolver if it
has “dnssec-validation auto;” in its configuration or if it has a root
trust anchor defined and has “dnssec-validation yes;” set (either by
accepting the default or via an explicitly set value of “yes”.) By
default ISC BIND recursive servers will not validate. (However, ISC
defaults may have been changed by your distributor.)
**CVE-2015-5477**
>TKEY query handling flaw leading to denial of service
>
>
>Versions affected: BIND 9.x before 9.9.7-P2 and 9.10.x before
9.10.2-P3
>
>Details
>
>A flaw was found in the way BIND handled requests for TKEY DNS
resource records. A remote attacker could use this flaw to make named
(functioning as an authoritative DNS server or a DNS resolver) exit
unexpectedly with an assertion failure via a specially crafted DNS
request packet.
Reference:
https://kb.isc.org/article/AA-01267
https://access.redhat.com/security/cve/CVE-2015-5477
*(from redmine: issue id 4506, created on 2015-08-03, closed on 2015-08-05)*
* Relations:
* parent #4505
* Changesets:
* Revision 94177d198b2c373d78e3bfeccefba287cea0899d by Natanael Copa on 2015-08-04T12:04:11Z:
```
main/bind: security upgrade to 9.9.7_p2 (CVE-2015-4620,CVE-2015-5477)
fixes #4506
```Alpine 2.7.10Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4505bind: DNS query issues (CVE-2015-4620, CVE-2015-5477)2019-07-23T13:49:46ZAlexander Belousbind: DNS query issues (CVE-2015-4620, CVE-2015-5477)**CVE-2015-4620**
>An attacker who can cause a validating resolver to query a zone
containing specifically constructed contents can cause that resolver to
fail an assertion and terminate due to a defect in validation code.
>
>Versio...**CVE-2015-4620**
>An attacker who can cause a validating resolver to query a zone
containing specifically constructed contents can cause that resolver to
fail an assertion and terminate due to a defect in validation code.
>
>Versions affected: BIND 9.7.1 ->9.7.7, 9.8.0 ->9.8.8, 9.9.0
->9.9.7, 9.10.0 ->9.10.2-P1.
>
>A very uncommon combination of zone data has been found that
triggers a bug in BIND, with the result that named will exit with a
“REQUIRE” failure in name.c when validating the data returned in answer
to a recursive query.
>
>
>This means that a recursive resolver that is performing DNSSEC
validation can be deliberately stopped by an attacker who can cause the
resolver to perform a query against a maliciously-constructed zone.
>
>
>Impact:
>
>A recursive resolver that is performing DNSSEC validation can be
deliberately terminated by any attacker who can cause a query to be
performed against a maliciously constructed zone. This will result in a
denial of service to clients who rely on that resolver.
>
>DNSSEC validation is only performed by a recursive resolver if it
has “dnssec-validation auto;” in its configuration or if it has a root
trust anchor defined and has “dnssec-validation yes;” set (either by
accepting the default or via an explicitly set value of “yes”.) By
default ISC BIND recursive servers will not validate. (However, ISC
defaults may have been changed by your distributor.)
**CVE-2015-5477**
>TKEY query handling flaw leading to denial of service
>Versions affected: BIND 9.x before 9.9.7-P2 and 9.10.x before
9.10.2-P3
>
>Details
>
>A flaw was found in the way BIND handled requests for TKEY DNS
resource records. A remote attacker could use this flaw to make named
(functioning as an authoritative DNS server or a DNS resolver) exit
unexpectedly with an assertion failure via a specially crafted DNS
request packet.
Reference:
https://kb.isc.org/article/AA-01267
https://access.redhat.com/security/cve/CVE-2015-5477
*(from redmine: issue id 4505, created on 2015-08-03, closed on 2015-08-05)*
* Relations:
* child #4506
* child #4507
* child #4508
* child #4509https://gitlab.alpinelinux.org/alpine/aports/-/issues/4504execline and imagemagick conflict on /usr/bin/import2019-07-14T22:21:01ZJesse Youngexecline and imagemagick conflict on /usr/bin/importOn edge, as of today, 2015 Jul 31
Both execline and imagemagick contain a /usr/bin/import file, preventing
the installation of both packages (and their respective reverse
dependencies) on the same Alpine installation.
I think the best ...On edge, as of today, 2015 Jul 31
Both execline and imagemagick contain a /usr/bin/import file, preventing
the installation of both packages (and their respective reverse
dependencies) on the same Alpine installation.
I think the best solution is contained in this unofficial debian
package:
[https://github.com/lwf/s6-packaging/tree/master/execline-2.0.1.1/debian](https://github.com/lwf/s6-packaging/tree/master/execline-2.0.1.1/debian)
Here, execline binaries are installed in /usr/lib/execline/bin, with an
additional /usr/bin/execlineb script that munges the $PATH and execs
into /usr/lib/execline/bin/execlineb.
skalibs should also be ./configure’d with —with-default-path= having
/usr/lib/execline/bin prepended to the default $PATH.
Thoughts? I’m willing to contribute a patch after getting feedback on
this idea. There’s a possibility of breaking existing scripts, such as
those that invoke an execline component binary outside of the execlineb
parser (which the execlineb wrapper script didn’t get a chance to
intercept to change the $PATH).
*(from redmine: issue id 4504, created on 2015-08-01)*Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4503Package request: HHVM2020-01-18T20:57:12ZAlejandro VidalPackage request: HHVMHHVM (Hip Hop Virtual Machine) is a virtual machine designed for
executing programs written in Hack and PHP using JIT compilation,
currently maintained by Facebook.
HHVM can be used side by side with PHP-FPM as fallback, which makes it ...HHVM (Hip Hop Virtual Machine) is a virtual machine designed for
executing programs written in Hack and PHP using JIT compilation,
currently maintained by Facebook.
HHVM can be used side by side with PHP-FPM as fallback, which makes it a
very interesting technology to try out today.
Alpine inside Docker containers is the perfect OS for optimal workloads.
In my attempts to run HHVM in Alpine I’ve copied the Debian binaries and
symlinked the corresponding libraries, but a few libraries are missing
(like libtbb) which .
I have no experience building Alpine packages (neither Debian) but it’s
something I want to learn and I think this is the right moment.
Any advice is really appreciated. I can take this issue, after learning
a few things about packaging.
A similar issue has been submitted to HHVM
https://github.com/facebook/hhvm/issues/5826
HHVM git repo
https://github.com/facebook/hhvm
Dockerfile to build inside Debian:
https://registry.hub.docker.com/u/mssola/hhvm/
HHVM dependency chain in Debian:
git-core
cmake
libmysqlclient-dev
libxml2-dev
libmcrypt-dev
libicu-dev
openssl
build-essential
binutils-dev
libcap-dev
zlib1g-dev
libtbb-dev
libonig-dev
libpcre3-dev
autoconf
libtool
libcurl4-openssl-dev
wget
memcached
libreadline-dev
libncurses5-dev
libmemcached-dev
libbz2-dev
libc-client2007e-dev
php5-mcrypt
php5-imagick
libgoogle-perftools-dev
libcloog-ppl-dev
libelf-dev
libdwarf-dev
libunwind8-dev
subversion
libtbb2
libtbb-dev
g<span class="underline"></span>–4.8
gcc-4.8
libjemalloc-dev
libc6-dev
libmpfr4
libgcc1
binutils
libc6
libc-dev-bin
libc-bin
libgomp1
libstdc<span class="underline"></span>–4.8-dev
libstdc++6
libarchive13
cmake-data
libacl1
libattr1
g<span class="underline"></span>
cpp
gcc
make
libboost-thread1.55.0
libboost-thread-dev
libgd2-xpm-dev
pkg-config
binutils-dev
libboost-system1.55-dev
libboost-program-options1.55-dev
libboost-filesystem1.55-dev
libboost-regex1.55-dev
libmagickwand-dev
libiberty-dev
libevent-dev
libxslt-dev
libgoogle-glog-dev
automake
libldap2-dev
libkrb5-dev
ocaml-native-compilers
sudo
*(from redmine: issue id 4503, created on 2015-07-31)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/4502[v3.2] net-snmp: snmp_pdu_parse() incompletely parsed varBinds left in list o...2019-07-23T13:49:47ZAlexander Belous[v3.2] net-snmp: snmp_pdu_parse() incompletely parsed varBinds left in list of variables (CVE-2015-5621)It was discovered that the snmp\_pdu\_parse() function could leave
incompletely parsed varBind variables in the list of variables in
case the parsing of the SNMP PDU failed. If later processing tries to
operate on the stale and inc...It was discovered that the snmp\_pdu\_parse() function could leave
incompletely parsed varBind variables in the list of variables in
case the parsing of the SNMP PDU failed. If later processing tries to
operate on the stale and incompletely processed varBind (e.g. when
printing the variables), this can lead to e.g. crashes or, possibly,
execution of arbitrary code (although I’ve only seen NULL pointer
dereferences during my testing, I currently can’t rule out code
execution completely).
The snmp\_pdu\_parse() function stores varBind variables in a list of
netsnmp\_variable\_list structures. Each time the function parses a
new
varBind, a new netsnmp\_variable\_list item is allocated on the heap
and linked to the list of variables. The problem is that this item
is not removed from the list, even if snmp\_pdu\_parse() fails to
complete the parsing.
The “type” member of the stale netsnmp\_variable\_list is not
properly initialized in case snmp\_pdu\_parse() returns early from the
parsing. However, the “type” member is used to determine later code
paths, which is why we see crashes in a variety of functions,
although the root cause for all of these is the same.
References:
https://bugzilla.redhat.com/show\_bug.cgi?id=1212408
Upstream patch:
https://sourceforge.net/p/net-snmp/code/ci/f23bcd3ac6ddee5d0a48f9703007ccc738914791/
Upstream bug:
https://sourceforge.net/p/net-snmp/bugs/2615/ (possibly restricted)
Reporter’s mail to oss-security:
http://www.openwall.com/lists/oss-security/2015/04/13/1
*(from redmine: issue id 4502, created on 2015-07-31, closed on 2015-08-05)*
* Relations:
* parent #4498
* Changesets:
* Revision 1cc17473b842734155ab967aa1d64e7941c44d28 by Natanael Copa on 2015-08-04T09:36:43Z:
```
main/net-snmp: security fix for CVE-2015-5621
fixes #4502
```3.2.3Carlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4501[v3.1] net-snmp: snmp_pdu_parse() incompletely parsed varBinds left in list o...2019-07-23T13:49:48ZAlexander Belous[v3.1] net-snmp: snmp_pdu_parse() incompletely parsed varBinds left in list of variables (CVE-2015-5621)It was discovered that the snmp\_pdu\_parse() function could leave
incompletely parsed varBind variables in the list of variables in
case the parsing of the SNMP PDU failed. If later processing tries to
operate on the stale and inc...It was discovered that the snmp\_pdu\_parse() function could leave
incompletely parsed varBind variables in the list of variables in
case the parsing of the SNMP PDU failed. If later processing tries to
operate on the stale and incompletely processed varBind (e.g. when
printing the variables), this can lead to e.g. crashes or, possibly,
execution of arbitrary code (although I’ve only seen NULL pointer
dereferences during my testing, I currently can’t rule out code
execution completely).
The snmp\_pdu\_parse() function stores varBind variables in a list of
netsnmp\_variable\_list structures. Each time the function parses a
new
varBind, a new netsnmp\_variable\_list item is allocated on the heap
and linked to the list of variables. The problem is that this item
is not removed from the list, even if snmp\_pdu\_parse() fails to
complete the parsing.
The “type” member of the stale netsnmp\_variable\_list is not
properly initialized in case snmp\_pdu\_parse() returns early from the
parsing. However, the “type” member is used to determine later code
paths, which is why we see crashes in a variety of functions,
although the root cause for all of these is the same.
References:
https://bugzilla.redhat.com/show\_bug.cgi?id=1212408
Upstream patch:
https://sourceforge.net/p/net-snmp/code/ci/f23bcd3ac6ddee5d0a48f9703007ccc738914791/
Upstream bug:
https://sourceforge.net/p/net-snmp/bugs/2615/ (possibly restricted)
Reporter’s mail to oss-security:
http://www.openwall.com/lists/oss-security/2015/04/13/1
*(from redmine: issue id 4501, created on 2015-07-31, closed on 2015-08-05)*
* Relations:
* parent #4498
* Changesets:
* Revision 952004e3925d2c79bbdc8415aeb08d9c2e57a29a by Natanael Copa on 2015-08-05T08:46:42Z:
```
main/net-snmp: security fix for CVE-2015-5621
fixes #4501
```3.1.5Carlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4500[v3.0] net-snmp: snmp_pdu_parse() incompletely parsed varBinds left in list o...2019-07-23T13:49:49ZAlexander Belous[v3.0] net-snmp: snmp_pdu_parse() incompletely parsed varBinds left in list of variables (CVE-2015-5621)It was discovered that the snmp\_pdu\_parse() function could leave
incompletely parsed varBind variables in the list of variables in
case the parsing of the SNMP PDU failed. If later processing tries to
operate on the stale and inc...It was discovered that the snmp\_pdu\_parse() function could leave
incompletely parsed varBind variables in the list of variables in
case the parsing of the SNMP PDU failed. If later processing tries to
operate on the stale and incompletely processed varBind (e.g. when
printing the variables), this can lead to e.g. crashes or, possibly,
execution of arbitrary code (although I’ve only seen NULL pointer
dereferences during my testing, I currently can’t rule out code
execution completely).
The snmp\_pdu\_parse() function stores varBind variables in a list of
netsnmp\_variable\_list structures. Each time the function parses a
new
varBind, a new netsnmp\_variable\_list item is allocated on the heap
and linked to the list of variables. The problem is that this item
is not removed from the list, even if snmp\_pdu\_parse() fails to
complete the parsing.
The “type” member of the stale netsnmp\_variable\_list is not
properly initialized in case snmp\_pdu\_parse() returns early from the
parsing. However, the “type” member is used to determine later code
paths, which is why we see crashes in a variety of functions,
although the root cause for all of these is the same.
References:
https://bugzilla.redhat.com/show\_bug.cgi?id=1212408
Upstream patch:
https://sourceforge.net/p/net-snmp/code/ci/f23bcd3ac6ddee5d0a48f9703007ccc738914791/
Upstream bug:
https://sourceforge.net/p/net-snmp/bugs/2615/ (possibly restricted)
Reporter’s mail to oss-security:
http://www.openwall.com/lists/oss-security/2015/04/13/1
*(from redmine: issue id 4500, created on 2015-07-31, closed on 2015-08-05)*
* Relations:
* parent #4498
* Changesets:
* Revision 7cdb08f4a0e7984d2b56cac22996f3fed4e089b2 by Natanael Copa on 2015-08-05T08:51:03Z:
```
main/net-snmp: security fix for CVE-2015-5621
fixes #4500
```3.0.7Carlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4499[v2.7] net-snmp: snmp_pdu_parse() incompletely parsed varBinds left in list o...2019-07-23T13:49:50ZAlexander Belous[v2.7] net-snmp: snmp_pdu_parse() incompletely parsed varBinds left in list of variables (CVE-2015-5621)It was discovered that the snmp\_pdu\_parse() function could leave
incompletely parsed varBind variables in the list of variables in
case the parsing of the SNMP PDU failed. If later processing tries to
operate on the stale and inc...It was discovered that the snmp\_pdu\_parse() function could leave
incompletely parsed varBind variables in the list of variables in
case the parsing of the SNMP PDU failed. If later processing tries to
operate on the stale and incompletely processed varBind (e.g. when
printing the variables), this can lead to e.g. crashes or, possibly,
execution of arbitrary code (although I’ve only seen NULL pointer
dereferences during my testing, I currently can’t rule out code
execution completely).
The snmp\_pdu\_parse() function stores varBind variables in a list of
netsnmp\_variable\_list structures. Each time the function parses a
new
varBind, a new netsnmp\_variable\_list item is allocated on the heap
and linked to the list of variables. The problem is that this item
is not removed from the list, even if snmp\_pdu\_parse() fails to
complete the parsing.
The “type” member of the stale netsnmp\_variable\_list is not
properly initialized in case snmp\_pdu\_parse() returns early from the
parsing. However, the “type” member is used to determine later code
paths, which is why we see crashes in a variety of functions,
although the root cause for all of these is the same.
References:
https://bugzilla.redhat.com/show\_bug.cgi?id=1212408
Upstream patch:
https://sourceforge.net/p/net-snmp/code/ci/f23bcd3ac6ddee5d0a48f9703007ccc738914791/
Upstream bug:
https://sourceforge.net/p/net-snmp/bugs/2615/ (possibly restricted)
Reporter’s mail to oss-security:
http://www.openwall.com/lists/oss-security/2015/04/13/1
*(from redmine: issue id 4499, created on 2015-07-31, closed on 2015-08-05)*
* Relations:
* parent #4498
* Changesets:
* Revision 09f1cb8fc8c006e59a36dd2930f62113cd7f38d4 by Natanael Copa on 2015-08-05T08:55:52Z:
```
main/net-snmp: security fix for CVE-2015-5621
fixes #4499
```Alpine 2.7.10Carlo LandmeterCarlo Landmeterhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4498net-snmp: snmp_pdu_parse() incompletely parsed varBinds left in list of varia...2019-07-23T13:49:51ZAlexander Belousnet-snmp: snmp_pdu_parse() incompletely parsed varBinds left in list of variables (CVE-2015-5621)It was discovered that the snmp\_pdu\_parse() function could leave
incompletely parsed varBind variables in the list of variables in
case the parsing of the SNMP PDU failed. If later processing tries to
operate on the stale and inc...It was discovered that the snmp\_pdu\_parse() function could leave
incompletely parsed varBind variables in the list of variables in
case the parsing of the SNMP PDU failed. If later processing tries to
operate on the stale and incompletely processed varBind (e.g. when
printing the variables), this can lead to e.g. crashes or, possibly,
execution of arbitrary code (although I’ve only seen NULL pointer
dereferences during my testing, I currently can’t rule out code
execution completely).
The snmp\_pdu\_parse() function stores varBind variables in a list of
netsnmp\_variable\_list structures. Each time the function parses a
new
varBind, a new netsnmp\_variable\_list item is allocated on the heap
and linked to the list of variables. The problem is that this item
is not removed from the list, even if snmp\_pdu\_parse() fails to
complete the parsing.
The “type” member of the stale netsnmp\_variable\_list is not
properly initialized in case snmp\_pdu\_parse() returns early from the
parsing. However, the “type” member is used to determine later code
paths, which is why we see crashes in a variety of functions,
although the root cause for all of these is the same.
References:
https://bugzilla.redhat.com/show\_bug.cgi?id=1212408
Upstream patch:
https://sourceforge.net/p/net-snmp/code/ci/f23bcd3ac6ddee5d0a48f9703007ccc738914791/
Upstream bug:
https://sourceforge.net/p/net-snmp/bugs/2615/ (possibly restricted)
Reporter’s mail to oss-security:
http://www.openwall.com/lists/oss-security/2015/04/13/1
*(from redmine: issue id 4498, created on 2015-07-31, closed on 2015-08-05)*
* Relations:
* child #4499
* child #4500
* child #4501
* child #4502https://gitlab.alpinelinux.org/alpine/aports/-/issues/4497main/erlang: vi can't read user input after quitting erl2019-07-15T14:22:52ZMarlus Saraivamain/erlang: vi can't read user input after quitting erlHow to reproduce:
$ apk add erlang
$ erl
Quit erl with double ctrl-c
$ vi anyfile.txt
Output:
vi: can't read user input
The problem only happens on version 18. Package erlang17 is ok.
Related to http://bugs.a...How to reproduce:
$ apk add erlang
$ erl
Quit erl with double ctrl-c
$ vi anyfile.txt
Output:
vi: can't read user input
The problem only happens on version 18. Package erlang17 is ok.
Related to http://bugs.alpinelinux.org/issues/2259
*(from redmine: issue id 4497, created on 2015-07-30)*https://gitlab.alpinelinux.org/alpine/aports/-/issues/4496[v3.0] qemu: heap overflow flaw while processing certain ATAPI commands (CVE-...2019-07-23T13:49:52ZAlexander Belous[v3.0] qemu: heap overflow flaw while processing certain ATAPI commands (CVE-2015-5154)The QEMU security team has predisclosed the following advisory:
A heap overflow flaw was found in the way QEMU’s IDE subsystem
handled I/O buffer access while processing certain ATAPI commands.
A privileged guest user in a guest wi...The QEMU security team has predisclosed the following advisory:
A heap overflow flaw was found in the way QEMU’s IDE subsystem
handled I/O buffer access while processing certain ATAPI commands.
A privileged guest user in a guest with CDROM drive enabled could
potentially use this flaw to execute arbitrary code on the host
with the privileges of the host’s QEMU process corresponding to
the guest.
IMPACT ==
An HVM guest which has access to an emulated IDE CDROM device
(e.g. with a device with “devtype=cdrom”, or the “cdrom” convenience
alias, in the VBD configuration) can exploit this vulnerability to
take over the qemu process elevating its privilege to that of the qemu
process.
VULNERABLE SYSTEMS ==
All Xen systems running x86 HVM guests without stubdomains which have
been configured with an emulated CD-ROM driver model are vulnerable.
Systems using qemu-dm stubdomain device models (for example, by
specifying “device\_model\_stubdomain\_override=1” in xl’s domain
configuration files) are NOT vulnerable.
Both the traditional (“qemu-xen-traditional”) or upstream-based
(“qemu-xen”) qemu device models are potentially vulnerable.
Systems running only PV guests are NOT vulnerable.
ARM systems are NOT vulnerable.
Reference:
http://seclists.org/oss-sec/2015/q3/212
*(from redmine: issue id 4496, created on 2015-07-30, closed on 2015-08-05)*
* Relations:
* parent #4493
* Changesets:
* Revision f987d4240c07db81b5a3a1111a5a4df6a734918f by Natanael Copa on 2015-08-05T12:18:32Z:
```
main/qemu: security fix for CVE-2015-5154
fixes #4496
```3.0.7Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/4495[v3.1] qemu: heap overflow flaw while processing certain ATAPI commands (CVE-...2019-07-23T13:49:53ZAlexander Belous[v3.1] qemu: heap overflow flaw while processing certain ATAPI commands (CVE-2015-5154)The QEMU security team has predisclosed the following advisory:
A heap overflow flaw was found in the way QEMU’s IDE subsystem
handled I/O buffer access while processing certain ATAPI commands.
A privileged guest user in a guest wi...The QEMU security team has predisclosed the following advisory:
A heap overflow flaw was found in the way QEMU’s IDE subsystem
handled I/O buffer access while processing certain ATAPI commands.
A privileged guest user in a guest with CDROM drive enabled could
potentially use this flaw to execute arbitrary code on the host
with the privileges of the host’s QEMU process corresponding to
the guest.
IMPACT ==
An HVM guest which has access to an emulated IDE CDROM device
(e.g. with a device with “devtype=cdrom”, or the “cdrom” convenience
alias, in the VBD configuration) can exploit this vulnerability to
take over the qemu process elevating its privilege to that of the qemu
process.
VULNERABLE SYSTEMS ==
All Xen systems running x86 HVM guests without stubdomains which have
been configured with an emulated CD-ROM driver model are vulnerable.
Systems using qemu-dm stubdomain device models (for example, by
specifying “device\_model\_stubdomain\_override=1” in xl’s domain
configuration files) are NOT vulnerable.
Both the traditional (“qemu-xen-traditional”) or upstream-based
(“qemu-xen”) qemu device models are potentially vulnerable.
Systems running only PV guests are NOT vulnerable.
ARM systems are NOT vulnerable.
Reference:
http://seclists.org/oss-sec/2015/q3/212
*(from redmine: issue id 4495, created on 2015-07-30, closed on 2015-08-05)*
* Relations:
* parent #4493
* Changesets:
* Revision 940bb1d7a2738797df28c3861c159eeafb691ba2 by Natanael Copa on 2015-08-05T10:04:27Z:
```
main/qemu: security fix for CVE-2015-5154
fixes #4495
```3.1.5Natanael CopaNatanael Copa