Re: Signature strength of .dsc
Jonathan McDowell writes: > On Mon, Dec 04, 2023 at 11:07:38AM +0100, Simon Josefsson wrote: >> Judit Foglszinger writes: >> >> > Dmitri, could you re-run the numbers with the debian-maintainer >> >> > keyring? >> >> >> >> That is correct. I have updated the results now. The 2,455 no >> >> public key has now become 1,238 >> > >> > Another is the DN keyring. Also I'd expect many keys to be found in >> > older versions of the keyring package/keyring repository and on >> > keyservers like keyserver.ubuntu.com >> >> Removing old keys is usually a bad idea -- could these be moved to a >> "archived" keyring instead? I assume having them in the "live" >> keyring is not possible if the presence of a key in that file is used >> to make authorization decisions. >> >> You want to be able to verify old signatures in 20+ years too, and >> then you need to be able to find the corresponding public key. > > For a long time we had a "removed" keyring, but we decided that we > didn't want to continue shipping a keyring that was explicitly a set of > keys we could not vouch for the trust of (whether that be because they > were revoked, lost, weak, or whatever). If you really want to find old > keys there is 15+ years of history in the keyring git repository, as > Judit mentioned: > > https://salsa.debian.org/debian-keyring/keyring/ I think that is unfortunate and not sustainable over time: you need to have access to the public keys to verify old signatures, and for as long as the old signatures are published we should make a public keyring for them easily available. Which I suspect means essentially forever, due to archive.debian.org. I don't think it doesn't really matter of the old public key is weak or invalid: if we know of a public key published at the time as some signature that was possible to verify using software available at that time, we should publish that public key. Was there a real practical situations that couldn't be resolved that lead to dropping the "removed" keyring? What was the details? Maybe this decision could be reverted with some effort. /Simon signature.asc Description: PGP signature
Bug#1057806: ITP: lxqt-menu-data -- menu files for LXQt Panel, Configuration Center and PCManFM-Qt/libfm-qt
Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬)
X-Debbugs-Cc: debian-devel@lists.debian.org, team+l...@tracker.debian.org
* Package name: lxqt-menu-data
Version : 1.4.1
Upstream Contact: tsujan
* URL : https://github.com/lxqt/lxqt-menu-data
* License : LGPL-2.1
Programming Lang: C++
Description : menu files for LXQt Panel, Configuration Center and
PCManFM-Qt/libfm-qt
Freedesktop.org compliant menu files for LXQt Panel, Configuration
Center and PCManFM-Qt/libfm-qt.
The package will be maintained under the umbrella of the LXQt team.
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
Debian Med video meeting tomorrow Saturday 2023-12-09 19:00 UTC
Hi, this is the call for the next video meeting of the Debian Med team that are an established means to organise the tasks inside our team. Meetings usually take us only 15-20min depending what we are talking about and how many people are joining. The next meeting is tomorrow https://www.timeanddate.com/worldclock/fixedtime.html?iso=20231209T19 Despite technical issues of the last meeting I think we stick to the known Debian Social channel https://jitsi.debian.social/DebianMedCovid19 The topic is what contributors have done in the past period and to coordinate the work until the next meeting. For those who are interested in hot topics we want to tackle, here are some items: - Status of BioConductor transition - Python 3.12 transition - Advent bug squashing Newcomers are always welcome. See you tomorrow Andreas. -- http://fam-tille.de
Re: Signature strength of .dsc
Am 8. Dezember 2023 18:56:00 MEZ schrieb Simon Josefsson : > >I think that is unfortunate and not sustainable over time: you need to >have access to the public keys to verify old signatures, and for as long >as the old signatures are published we should make a public keyring for >them easily available. Which I suspect means essentially forever, due >to archive.debian.org. But certainly there are keyring packages on archive.d.o in the archived releases that hold the keys for the packages found within the resp. release? (modulo the problem we are facing right now: missing keys of packages uploaded aeons before the resp. release). I probably agree that it would be /nice/ (though I don't think: necessary) to have a keyring package in a given release that includes all keys that were used to bring the packages into that very release (that is: if a package was uploaded 10 years ago, the old key used to upload this package should be included somehow). But I don't see why we would need to ship (in a current package) all keys that were ever used in the history of Debian, just because somebody might do some archeology in the archives. mfh.her.fsr IOhannes
Bug#1057819: ITP: session-token -- command-line script for generating session tokens
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: session-token Version : 0.102 Upstream Author : Doug Hoyte * URL : https://metacpan.org/release/App-Session-Token * License : Artistic or GPL-1+ Programming Lang: Perl Description : command-line script for generating session tokens session-token is a script, using the Session::Token module, to create session tokens, password reset codes, temporary passwords, random identifiers, etc. It performs a similar task as `openssl rand -base64 16' but is more flexible regarding the alphabet used, and can efficiently generate a large number of random tokens. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
