Maintainer for gnupg (and related) packages not responding – CVE unfixed
by Christian Stadelmann
Hi
I'm writing here since there are many known bugs (mostly fixed upstream), including at least one CVE in a bunch of packages critical to Fedora's integrity.
Libgcrypt:
Version 1.7.2 is available: https://bugzilla.redhat.com/show_bug.cgi?id=1306064 (note that 3 updates were missed)
CVE-2015-7511 libgcrypt: side-channel attack on ECDH with Weierstrass curves [fedora-all]: https://bugzilla.redhat.com/show_bug.cgi?id=1306185
gnupg2:
gnupg2 hasn't seen an update in 2 months (3 versions) to Fedora stable. According to this automatically created bug report https://bugzilla.redhat.com/show_bug.cgi?id=1230986 the maintainer has not managed to ship the latest version in >1 year.
This is not only bad behavior of the maintainer, it also is a bad sign on how security critical updates are handled in Fedora. Those two packages are effectively unmaintained although all of Fedora's security is based on them. This is a pretty ugly situation which needs your attention and (probably) some action.
The second bug report against libgcrypt has an CVE assigned and still it is unfixed for months. This must not happen too. There should be some mechanism to notify somebody if a maintainer doesn't act on CVEs within 3 days.
7 years, 2 months
LiveUSBCreator as Primary Downloadable
by Chris Murphy
https://bugzilla.redhat.com/show_bug.cgi?id=1310542
https://fedorahosted.org/fedora-security-team/ticket/1
I'm not sure if this belongs in security@ or security-team@ so I've
just flipped a coin.
On macOS there are three distribution+security paths:
- unsigned, and the user is blocked from running the app by default
but they can disable this one time for that application installer or
for all installers
- dev signed, developer distributed
- dev signed, and Apple signed, App Store distributed
Dev keys are only available through the Apple Developer Program, and
only sign code through XCode. There is a way to sign code through a
3rd party but macOS treats it as unsigned, the user would have to use
the CLI to verify the signing of the binary.
There are details in here I'm not certain of, but there is a
qualitative difference in sandboxing of App Store distributed apps.
I'm not certain they can do privilege escalation. In order to image an
ISO to a USB stick on macOS I have to use 'sudo dd' to have the
privileges to write to a raw device.
As for compiling, I'm not totally certain it has to happen within
XCode on macOS, but the signing of the binary happens with XCode which
only runs on macOS. Primary development can happen elsewhere, but
eventually it gets built on Apple hardware, OS, and dev tools. A good
chunk of that is controllable by CLI.
I wonder if there's a way to ship this as a Docker for Mac container
instead? It's still beta, but uses HyperKit framework which is an
Apple provided library rather than depending on VirtualBox. So I'd
also consider evaluating this path since it may turn out to be the
path of least resistance for getting an initial tool on macOS.
--
Chris Murphy
7 years, 2 months