Paul Gevers
2019-07-03 20:10:01 UTC
Control: tags -1 wontfix
Hi Jonathan,
get it uploaded to their archive, because I don't understand why that
wouldn't work.
freeze and your issue is not a we-can-release-otherwise problem. If you
are right it can't be fixed via security, we can document it in the
release notes as you say. The problem you are having is not new, see
e.g. bug 578117.
Paul
Hi Jonathan,
I realise it's 3 days before release weekend, this upload fixes a problem
that we can't really fix in a security update.
Can you elaborate why not? I suggest you talk to the security team tothat we can't really fix in a security update.
get it uploaded to their archive, because I don't understand why that
wouldn't work.
Yesterday a user discovered
that their encryption key for their hard disk in a full-disk-encryption
setup is world-readable on debian-based systems using initramfs-tools.
This affects Calamares users who can now install Debian on in an easy to
https://github.com/calamares/calamares/issues/1191
https://nvd.nist.gov/vuln/detail/CVE-2019-13179
"""
# Set secure permissions for the initramfs,
# the initramfs is re-generated later in the installation process
echo "UMASK=0077" > $CHROOT/etc/initramfs-tools/conf.d/initramfs-permissions
"""
Which will cause "update-initramfs -u" that runs later in the script to write
the initramfs with safe permissions.
Without this upload, users will have to write that file theirselves in order
to have a setup safe from local users (or users on the system with filesystem
access). In such a case we'll note it in the release notes, but I would urge
the release team to consider it if there is still any possibility.
Sorry, too late. I agree that this isn't pretty, but we are in the hardthat their encryption key for their hard disk in a full-disk-encryption
setup is world-readable on debian-based systems using initramfs-tools.
This affects Calamares users who can now install Debian on in an easy to
https://github.com/calamares/calamares/issues/1191
https://nvd.nist.gov/vuln/detail/CVE-2019-13179
"""
# Set secure permissions for the initramfs,
# the initramfs is re-generated later in the installation process
echo "UMASK=0077" > $CHROOT/etc/initramfs-tools/conf.d/initramfs-permissions
"""
Which will cause "update-initramfs -u" that runs later in the script to write
the initramfs with safe permissions.
Without this upload, users will have to write that file theirselves in order
to have a setup safe from local users (or users on the system with filesystem
access). In such a case we'll note it in the release notes, but I would urge
the release team to consider it if there is still any possibility.
freeze and your issue is not a we-can-release-otherwise problem. If you
are right it can't be fixed via security, we can document it in the
release notes as you say. The problem you are having is not new, see
e.g. bug 578117.
Paul