TSC issueshttps://gitlab.alpinelinux.org/alpine/tsc/-/issues2023-12-07T15:29:56Zhttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/75Determine requirements for developers with direct push access2023-12-07T15:29:56ZKevin DaudtDetermine requirements for developers with direct push accessIt should be good to reevaluate what our criteria are for adding new developers, since the security landscape is continuously changing and threats increase.It should be good to reevaluate what our criteria are for adding new developers, since the security landscape is continuously changing and threats increase.https://gitlab.alpinelinux.org/alpine/tsc/-/issues/60Establish process to grant commit rights to aports to community members2023-04-01T13:44:20ZDrew DeVaultEstablish process to grant commit rights to aports to community membersA process needs to be introduced by which members of the Alpine community member can petition for and receive commit rights to aports so that they may more easily maintain the packages that they maintain.
This should be treated as a hig...A process needs to be introduced by which members of the Alpine community member can petition for and receive commit rights to aports so that they may more easily maintain the packages that they maintain.
This should be treated as a high-priority issue for the TSC.
Related: #57
Begin personal opinions:
I do not think that this should be blocked on any kind of broader plans to introduce larger organizational structures into Alpine. If such considerations are necessary, a stop-gap solution should be arrived at and implemented quickly with the understanding that it may change when Alpine finishes developing a more formal governance structure.
I also do not think that this should be blocked on technical problems, such as the desire to install a suitably granular permissions system such that maintainers cannot push to packages that they do not own. The absence of such per-requisites may call for a higher standard to which potential committers are held, and can be lowered if more granular permissions management becomes possible.https://gitlab.alpinelinux.org/alpine/tsc/-/issues/49Consider asynchronous TSC meetings2022-06-16T16:29:43ZKevin DaudtConsider asynchronous TSC meetingsIt has been a challenge to reach quorum for TSC meetings, which then have to be rescheduled.
There are numerous solutions. This proposal is it consider making the TSC meetings asynchronous, meaning no longer using video calls where ever...It has been a challenge to reach quorum for TSC meetings, which then have to be rescheduled.
There are numerous solutions. This proposal is it consider making the TSC meetings asynchronous, meaning no longer using video calls where everyone has to be present.
Making these meetings asynchronous does have impact on the defined workflow, so that would have to be rewritten.
Advantages:
* Not everyone needs to be present at the same time
* Some people dislike taking part in video calls, which would exclude them from participating and therefor being TSC members
* Potentially more transparency (easier / more acceptable to publish chat transcripts if everyone agrees instead of video recordings)
Disadvantages:
* Harder to add nuance in discussions
* Finalizing decisions takes longerhttps://gitlab.alpinelinux.org/alpine/tsc/-/issues/45ban indiscriminate setcap usage2023-06-15T11:04:44ZAlex Xu (Hello71)ban indiscriminate setcap usagemany aports use setcap on globally-executable programs. almost always, this is wrong. one egregious example is earlyoom, which does `setcap 'cap_kill,cap_ipc_lock,cap_setpcap=+ep' usr/bin/earlyoom`. this allows any user on the system to ...many aports use setcap on globally-executable programs. almost always, this is wrong. one egregious example is earlyoom, which does `setcap 'cap_kill,cap_ipc_lock,cap_setpcap=+ep' usr/bin/earlyoom`. this allows any user on the system to trivially kill selective processes by simply running `earlyoom -m 99 --prefer whatever`. `cap_setpcap` is even more terrible, since it could potentially allow bypassing the entire multi-user security framework, and apparently isn't even needed by earlyoom? similarly, timed does `setcap cap_sys_time+ep "$pkgdir"/usr/bin/timed-qt5`, which i believe allows anybody on the system to arbitrarily manipulate the system clock.
most packages do not do such terrible things, and only unnecessarily set cap_net_bind_service=+ep, or worse, cap_net_bind_service+eip, on main binary. while low-port security is not a critical aspect of modern Linux security, this could potentially be combined with e.g. killing sshd (see earlier) to install a fake sshd on port 22 to harvest passwords (albeit with wrong host keys).
it appears that in most cases, this is used as a dangerously insecure alternative to proper privilege separation in init script. the correct solution is to either use the program's own privilege dropping, or `setpriv --reuid=UID --regid=GID --init-groups --inh-caps +whatever --ambient-caps +whatever`, or some capsh equivalent. the latter two require separate helper programs to be installed (busybox setpriv is near-useless).
of current aports, kwin and powerdevil are ok because they use setcap to remove caps, not add them; netdata, wireshark, and i believe fping are ok because the programs are specifically designed to be suid; mpd and sn0int are dubious; earlyoom, timed, and probably corerad, nebula, ubridge, conntracct, and pcsx2 have serious vulnerabilities; and the rest give everybody cap_net_bind_service which is insecure but probably not horribly so.
in general, simply installing packages should not introduce new security vulnerabilities. using setcap on programs which were not specifically designed for it almost always results in this. therefore, i believe such usage should be prohibited, with exceptions on a case-by-case basis (netdata, wireshark, fping).https://gitlab.alpinelinux.org/alpine/tsc/-/issues/36Policy for non-maintainer updates to aports2022-06-07T12:42:03ZKevin DaudtPolicy for non-maintainer updates to aportsSeveral incidents make it clear we should create a policy around updates to packages to which the author is not the maintainer.
It should be clear for every developer what they can an cannot do. This is closely related to documenting [t...Several incidents make it clear we should create a policy around updates to packages to which the author is not the maintainer.
It should be clear for every developer what they can an cannot do. This is closely related to documenting [the responsibilities of a maintainer](#22).Kevin DaudtKevin Daudt2022-06-21https://gitlab.alpinelinux.org/alpine/tsc/-/issues/24Stable releases for riscv642021-12-04T13:18:01ZCarlo LandmeterStable releases for riscv64riscv64 currently builds in qemu-user with default option=!check (do not run tests).
Do we want to ship a stable release if our other release do have some sort of quality control inside our build process?riscv64 currently builds in qemu-user with default option=!check (do not run tests).
Do we want to ship a stable release if our other release do have some sort of quality control inside our build process?https://gitlab.alpinelinux.org/alpine/tsc/-/issues/22Maintainer responsibilities and privileges2022-06-07T10:58:24ZKaarle RitvanenMaintainer responsibilities and privilegesAs per the TSC decision, I am opening this issue for the purpose of defining the responsibilities and privileges of the package maintainers. To start the discussion, here are some preliminary ideas:
* responsibilities:
* providing f...As per the TSC decision, I am opening this issue for the purpose of defining the responsibilities and privileges of the package maintainers. To start the discussion, here are some preliminary ideas:
* responsibilities:
* providing fresh upstream releases on edge, preferably the latest release
but also considering
* support lifecycle compatibility between upstream and AL policy, and
* compatibility with depending packages
* on edge and all stable branches under active maintenance:
* fixing issues related to building and compatibility with the base
system
* backporting critical bug fixes from upstream
* fixing major security issues promptly
* adherence to TSC decisions and policies
* privileges:
* delegation of maintenance work to others who volunteer to help
* rejecting non-trivial changes
* reverting commits
In addition, we might want to define the processes for becoming a maintainer of a package and resigning as the maintainer.https://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-30https://gitlab.alpinelinux.org/alpine/tsc/-/issues/11Define the scope of the TSC2024-02-13T17:58:10ZCarlo LandmeterDefine the scope of the TSCAs Kevin pointed out we should define the scope of the TSC.
This has been roughly discussed before but it would be nice to put this on paper.
Let's use this issue to write things down and make it official via docs.a.o.As Kevin pointed out we should define the scope of the TSC.
This has been roughly discussed before but it would be nice to put this on paper.
Let's use this issue to write things down and make it official via docs.a.o.https://gitlab.alpinelinux.org/alpine/tsc/-/issues/8define process for moving things from main to community2022-06-28T15:50:51ZAriadne Conillariadne@ariadne.spacedefine process for moving things from main to communityA few times things have been moved to `community`, which shouldn't have been. We should define a process for handling these moves so that things like `gpsd` do not get moved to community, when they are needed by users who only want to u...A few times things have been moved to `community`, which shouldn't have been. We should define a process for handling these moves so that things like `gpsd` do not get moved to community, when they are needed by users who only want to use `main` repo.https://gitlab.alpinelinux.org/alpine/tsc/-/issues/2deadline for packages in testing2023-11-08T07:26:24ZAriadne Conillariadne@ariadne.spacedeadline for packages in testingFrequently, `testing` gets packages contributed to it which never leave and just bitrot.
I would like to propose a deadline for packages in `testing`: they either get moved to `community` or `main`, or they get removed within some time ...Frequently, `testing` gets packages contributed to it which never leave and just bitrot.
I would like to propose a deadline for packages in `testing`: they either get moved to `community` or `main`, or they get removed within some time limit.
I think a deadline will also motivate packagers to more actively participate in the maintenance of their packages.
Thoughts?Carlo LandmeterCarlo Landmeter