TSC issueshttps://gitlab.alpinelinux.org/alpine/tsc/-/issues2022-05-16T14:51:32Zhttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/42make mountpoints shared2022-05-16T14:51:32ZDominique Martinetmake mountpoints sharedHello,
I'd be interested in having / mounted as shared, either by default or as an option.
(Feel free to tell me to go open an issue [in openrc](https://github.com/OpenRC/openrc/issues) instead)
The rationale for this is that I selfi...Hello,
I'd be interested in having / mounted as shared, either by default or as an option.
(Feel free to tell me to go open an issue [in openrc](https://github.com/OpenRC/openrc/issues) instead)
The rationale for this is that I selfishly need to have some mountpoints mounted as shared for some container usages (when alpine is the host OS), in order to backpropagate mounts made by a privileged container in a volume marked as 'shared'.
In my case the volumes shouldn't be made directly off /, so just marking the FS where volumes should be as shared is probably going to be enough but it's not something I have direct control of so I'd be more comfortable with / marked shared as systemd has been doing (not a great argument admittedly... But it's what users are used to)
FWIW, it looks like podman 4 in rootless mode also seems to depend on it: https://github.com/containers/podman/discussions/12721 and aports#13541 (the hang might not be related but it illustrates the warning message being shown), so we might get other requests at this point.
With all that said, the question would be where to do it -- I think openrc's init.d/root might be the place, if a user adds shared to fstab, `fstabinfo -o /` will print it and we can `mount --make-(r)shared /` at this point (or other way around if it's to be made default -- do it here unless there's "private" in the fstab options), but perhaps there is a better way I'm not aware of?
Or should I just do it in my container starting service, and not bother the rest of alpine with it?
Thanks!https://gitlab.alpinelinux.org/alpine/tsc/-/issues/39[3.17] replace busybox ash with another /bin/sh2023-05-18T19:51:42ZAriadne Conillariadne@ariadne.space[3.17] replace busybox ash with another /bin/shWe've stared deep into the void of the busybox ash parsing code and found it staring back. Among other things we've found:
* `mempcpy` used in a situation where `memmove` must be used
* a serious shell substitution bug
* attempting to ...We've stared deep into the void of the busybox ash parsing code and found it staring back. Among other things we've found:
* `mempcpy` used in a situation where `memmove` must be used
* a serious shell substitution bug
* attempting to zero memory used by AST nodes in the stack code makes the whole thing violently explode, which should not ever happen in an otherwise correct codebase
This issue is about proposing a replacement /bin/sh. We want something similar to what we have now, but with a cleaner codebase, probably `mksh` or something.2022-10-01https://gitlab.alpinelinux.org/alpine/tsc/-/issues/17alpine-glibc2022-06-06T17:42:35ZAriadne Conillariadne@ariadne.spacealpine-glibcIt has come to the security team's attention that there are Docker images that make use of `alpine-pkg-glibc`.
It has also come to the security team's attention that end users and developers of these Docker images believe that `alpine-p...It has come to the security team's attention that there are Docker images that make use of `alpine-pkg-glibc`.
It has also come to the security team's attention that end users and developers of these Docker images believe that `alpine-pkg-glibc` is supported by the Alpine community in some way, which it obviously is not.
aports!24647 was a proposed update to `musl` which blocks installation of the glibc packages provided by the `alpine-pkg-glibc` project. The `alpine-pkg-glibc` project may rebuild the `musl` package with `ALLOW_GLIBC_PKG=1` in `abuild.conf` if they wish to provide their own `musl` package in their repo. We have concluded based on informal consensus to approach this as a documentation issue instead.
We may also wish to request the `alpine-pkg-glibc` project rename itself in order to make it more clear to the community that it is NOT an officially blessed project of Alpine, but that is an issue for the council.
Thusly, there are two items referred:
* ~~Should we accept the proposed `musl-1.2.2-r6` update into `edge`?~~
* Should we refer the `alpine-glibc` branding issue to the council to follow up on?2021-08-30