Re: Reaction to potential PGP schism
Daniel Kahn Gillmor wrote... (...) Thanks for your exhaustive description. I'd just like to point out one point: > In practice, i think it makes the most sense to engage with > well-documented, community-reviewed, interoperably-tested standards, and > the implementations that try to follow them. From my vantage point, > that looks like the OpenPGP projects that have continued to actively > engage in the IETF process, and have put in work to improve their > interoperability on the most sophisticated suite of OpenPGP tests that > we have (https://tests.sequoia-pgp.org/, maintained by the Sequoia > project for the community's benefit). Projects that work in that way > are also likely to benefit from smoother upgrades to upcoming work in > the IETF like post-quantum cryptographic schemes: > > https://datatracker.ietf.org/doc/draft-wussler-openpgp-pqc/ There was a presentation at the recent MiniDebconf in Cambridge about post-quantum cryptography, including the consequences for Debian (that was by Andy Simpkins): https://wiki.debian.org/DebianEvents/gb/2023/MiniDebConfCambridge/Simpkins The key point AIUI is Debian must take precautions *very* *soon* as there's a realistic chance QC will - within the lifetime of trixie - evolve to a point where it seriously weakens the cryptographic security as we know it. In other words, Debian must prepare for PQC within the trixie development cycle, so within 2024. Therefore, my answer to "How can Debian deal with this [schism]?" is basically: Debian needs to change things in that area anyway, let's first find an implementation that provides what we need and has a sane implementation. If that means turning away from GnuPG, so be it. The transition will be painful anyway. Christoph signature.asc Description: PGP signature
Re: HTTPS enabled Debian Security repository
林博仁 wrote... > I believe that there's no benefit on accessing Debian archive with HTTPS as > they uses GnuPG for authentication GnuPG indeed serves the purposes of authenticity and integrity very well. Modulo bugs every now and then, but they happen on other layers as well. Also, nobody should rely on the privacy in this case since the server content is public and the clients have a fairly simple access pattern. Decoding the transfers from this isn't trival but seems doable with some effort - one day I'll write a prove of concept for this. There is however a reason for https, a sad one though: Braindead "security" applicances that do deep packet inspection and might reject the download of packages. Christoph signature.asc Description: Digital signature
Re: Fwd: Re: [scr330159] lintian - 2.5.41, not fixed yet
Niels Thykier wrote... > > Deserialization vulnerability in lintian through 2.5.50.3 > > allows attackers to trigger code execution by requesting a review of > > a source package with a crafted YAML file. In my opinion lintian is just the victim of an issue in the YAML::XS module (libyaml-libyaml-perl) where serialized objects are re-instantiatiated unconditionally. To resolve that problem, I've started a discussion on the debian-perl@ list. Christoph signature.asc Description: Digital signature
Re: Some Debian package upgrades are corrupting rsync "quick check" backups
Adam Warner wrote... > Why is a 27 January recompilation of the source package purporting to > have the same modification time as the original binary package > distributed 16 days earlier? Lemme guess: For the sake of reproducible builds, the timestamp of all created files is set to the time of the latest changelog entry. > I suggest an rsync --checksum test on your backups (using > --itemize-changes and --dry-run to check for modifications without > making changes to the destination). This is an ugly situation. Always using --checksum brings a huge penalty indeed. The rsync program could take the source file's ctime into account but I doubt there's support for that. To me it seems saner to change Debian's workflow. Adding a new changelog entry for a binNMU would break a lot of things, though. The least intrusive but quite hacky way I can think of was to modify the timestamp by adding one second for the first binNMU and so on. Nothing that gets implemented over night, though. Christoph signature.asc Description: Digital signature
Re: HTTPS needs to be implemented for updating
Marc Haber wrote... > On Wed, Dec 21, 2016 at 09:31:23AM +0100, Joerg Jaspert wrote: > > Now, if you want to manually download a .deb and dpkg -i it - then you > > have to manually do the same steps apt & co do: Get the corresponding > > packages and (In)Release files, verify its signature validates against > > the archive key, then verify the checksum of the Packages and then the > > .deb file. If you don't follow this, you lost, but you asked for it. > > Do we have a tool that does this kind of verification of a locally > present .deb automatically? If it's about a package in the configured sources.list, you can just apt-get download it. Else I'd set up a virtual environment for the selected dist and arch, then apt-get download as above. There are several tools for that, chdist (src:devscripts) worked fine for me. Christoph signature.asc Description: Digital signature
Re: HTTPS needs to be implemented for updating
Casper Thomsen wrote... > On Sun, Dec 18, 2016 at 12:35 PM, datanoise wrote: > > There could be https mirrors as well as non-https mirrors. > > There is https://cloudfront.debian.net which you could decide to trust. > > It doesn't *need* to be a "Debian SSL cert"; since you trust the > mirror anyway is some regard, you could as well "just" also trust the > mirror's certificate (and handling thereof). Well, this creates trust for the path until (but excluding) that particular mirror only. Can I trust the mirror? And even if, there's no guarantee the mirror got the data through a trusted path. Christoph signature.asc Description: Digital signature
Re: [SECURITY] [DSA 3121-1] file security update
Henrique de Moraes Holschuh wrote... > I do have a private backport of file/5.21+15, but it is a quick hack job > that dropped multiarch and build-profile support to ease backporting. If > someone has a better backport that preserves multiarch support, please > upload. file maintainer here. I don't have upload permission for backports, so I cannot do the upload. I can and will however prepare one and run my extensive regression tests against it. If somebody is willing to do the upload part as a long-term commitment, please drop me a line. Christoph signature.asc Description: Digital signature
Re: [SECURITY] [DSA 3074-1] php5 security update
Christoph Biedl wrote...
> +[ -x /usr/bin/lsof ] && /usr/bin/lsof -w -l +d "${1}" -F0 | sed -zne
> "s/^n//p" | xargs -0i echo touch -c -h "'{}'"
Addendum, that "echo" rather looks like debugging.
Christoph
signature.asc
Description: Digital signature
Re: [SECURITY] [DSA 3074-1] php5 security update
Yves-Alexis Perez wrote...
> -
> Debian Security Advisory DSA-3074-1 secur...@debian.org
> http://www.debian.org/security/ Yves-Alexis Perez
> November 18, 2014 http://www.debian.org/security/faq
> -
>
> Package: php5
> CVE ID : CVE-2014-3710
> Debian Bug : 68283
Um, that number is wrong. It isn't #768283 either.
Worse, that update broke things:
| From: root@ (Cron Daemon)
| To: root@
| Subject: Cron > [ -x /usr/lib/php5/maxlifetime ] && [
-x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] &&
/usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime)
|
| sed: invalid option -- 'z'
| Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...
|
| -n, --quiet, --silent
| suppress automatic printing of pattern space
The -z option isn't available in the wheezy version of sed. For the
records, this is the change in sessionclean:
--- /tmp/sessionclean 2014-10-20 11:03:53.0 +0200
+++ /usr/lib/php5/sessionclean 2014-11-18 08:02:56.0 +0100
@@ -1,7 +1,7 @@
#!/bin/sh
# first find all used files and touch them (hope it's not massive amount of
files)
-[ -x /usr/bin/lsof ] && /usr/bin/lsof -w -l +d "${1}" | awk -- '{ if (NR > 1)
{ print $9; } }' | xargs -i touch -c {}
+[ -x /usr/bin/lsof ] && /usr/bin/lsof -w -l +d "${1}" -F0 | sed -zne "s/^n//p"
| xargs -0i echo touch -c -h "'{}'"
# find all files older then maxlifetime
find "${1}" -depth -mindepth 1 -maxdepth 1 -ignore_readdir_race -type f -cmin
"+${2}" -delete
Regards,
Christoph
signature.asc
Description: Digital signature
Re: [SECURITY] [DSA 2858-1] iceweasel security update
Hello Debian security, Moritz Muehlenhoff wrote... > Package: iceweasel (...) > This update updates Iceweasel to the ESR24 series of Firefox. Unfortunately, this upgrade broke the xul-ext-certificatepatrol package (src:certificatepatrol) in stable due to "Breaks: ... iceweasel (>= 19.0+)" there. There's already an updated package in stable-proposed-updates[0]. Since the next point release is several weeks away, this leaves stable users in an unpleseant situation of xul-ext-certificatepatrol being unavailable (or not upgrading iceweasel). So, could you consider releasing an upgraded src:certificatepatrol shortly to rectifiy that situation? A debdiff is linked in that document, let me know if you need more information. Regards, Christoph [0] https://release.debian.org/proposed-updates/stable.html signature.asc Description: Digital signature
