aports issueshttps://gitlab.alpinelinux.org/alpine/aports/-/issues2024-03-17T09:38:41Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15877py3-cryptography 42.0.5 - to mitigate CVE scanners2024-03-17T09:38:41ZBrandt, Sebastian (ITO-PC)py3-cryptography 42.0.5 - to mitigate CVE scanners<!--
This is the issue template for reporting an issue with a specific package. You
can select a different issue template from the dropdown above. Also, feel free
to use the "No template" option in case no template applies to your issue....<!--
This is the issue template for reporting an issue with a specific package. You
can select a different issue template from the dropdown above. Also, feel free
to use the "No template" option in case no template applies to your issue.
Also note that this repository is intended for reporting issues with packages.
For other components, separate issue trackers exist:
* Installer issues: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues
* Infrastructure issues: https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues
* Initramfs issues: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues
-->
## Package Information
* Package name: *py3-cryptography*
* Package version: *41.0.7-r0*
* Alpine version: *3.19.1*
* Alpine architecture: *aarch64*
## Summary
CVE-2023-50782 and CVE-2024-26130 are within the current version not fixed. We would need to update at least to 42.0.4, so that CVE scanners are happy. Latest version currently is 42.0.5Duncan BellamyDuncan Bellamyhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/15785OpenEXR is affected by CVE-2023-58412024-03-27T19:28:59ZAlex PyrgiotisOpenEXR is affected by CVE-2023-5841OpenEXR has made a [3.1.12](https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.1.12) release that tackles [CVE-2023-5841](https://takeonme.org/cves/CVE-2023-5841.html). Since this CVE has a Critical score, it will light...OpenEXR has made a [3.1.12](https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v3.1.12) release that tackles [CVE-2023-5841](https://takeonme.org/cves/CVE-2023-5841.html). Since this CVE has a Critical score, it will light up on most security scanners. Would it be feasible to update to the newest version?https://gitlab.alpinelinux.org/alpine/aports/-/issues/15409The `video` group mixes permissions for video output and input devices2023-11-20T10:47:42ZHugo BarreraThe `video` group mixes permissions for video output and input devicesTLDR: when a user is made a member of the `video` group in order to have access to webcam devices, that user and all their processes also have unrestricted access to raw video output device nodes.
I have [reported this upstream to `eude...TLDR: when a user is made a member of the `video` group in order to have access to webcam devices, that user and all their processes also have unrestricted access to raw video output device nodes.
I have [reported this upstream to `eudev`](https://github.com/eudev-project/eudev/issues/268) too, but I wouldn't count on this being fixed soon.
Wayland compositors use something like `seatd` or `elogind` to access video output hardware and input devices (mouse, keyboards, etc). This means that they don't need access to the hardware device itself. The recommendation from upstream (e.g.: developers of compositors and tools like `seatd`) is that users don't need to be a member of the `video` group. This prevents other user processes from having unrestricted access to the video output device.
If a user account can't access the device nodes, then neither can the processes or sandboxes that this user spawn.
Currently on Alpine, the `video` group has two purposes:
- Granting access to video output devices (e.g.: `drm`).
- Granting access to video input devices such as webcams.
If I want an account to have access to a webcam, it also immediately gets access to the hardware rendering device (and can, for example, screen-record what other users are doing, screen-spoof, etc).
## Potential solution
I think that the correct fix for this is:
- Keep using the `video` group for video output devices (this minimises breakage for existing installations).
- Use the `camera` group for webcams and other video input devices.
This requires patching several `udev` rules, both from `eudev` itself and third party rules.
This is a breaking change, and should be announced as such (it requires user intervention in most scenarios which make use of this group). I think that this specific approach is the least-breaking one, since it won't break existing Alpine installations which actually do require direct access to video hardware.
Sadly, this might spawn a wave of "my webcam stopped working" questions on IRC.
Before sending out patches, I'd like to hear what others think about this. This issue affects both Alpine and upstream, so this might need to be a coordinated effort).https://gitlab.alpinelinux.org/alpine/aports/-/issues/15309Request to patch latest gcc version to alpine v3.162024-01-24T13:27:03ZAkarsh ShettyRequest to patch latest gcc version to alpine v3.16Request to patch latest gcc version to alpine v3.16 to fix the CVE-2023-4039.Request to patch latest gcc version to alpine v3.16 to fix the CVE-2023-4039.Natanael CopaNatanael Copahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12943main/unbound: enable --with-deprecate-rsa-10242021-08-23T12:53:37ZJakub Jirutkamain/unbound: enable --with-deprecate-rsa-1024From the changelog:
> Add ./configure --with-deprecate-rsa-1024 that **turns off** RSA 1024.
When I build it with `--with-deprecate-rsa-1024`, the tests fail:
```
test services/authzone.c:auth_zone_verify_zonemd
assertion failure test...From the changelog:
> Add ./configure --with-deprecate-rsa-1024 that **turns off** RSA 1024.
When I build it with `--with-deprecate-rsa-1024`, the tests fail:
```
test services/authzone.c:auth_zone_verify_zonemd
assertion failure testcode/unitzonemd.c:314
make: *** [Makefile:342: test] Error 1
```
Follow-up from https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/24191#note_173950.