Package signatures tools
I'm releasing these things now... have them in development and use for a couple weeks/months now. A Python module for doing debsigs-type package signatures and verification thereof. Uses and included module for GnuPG file signatures and verification. It also includes a miniscript that, given a .changes file, signs the .deb, the .dsc and the .changes file (with the md5s in .changes adjusted). jerhard.org/files/python-debsigs-snapshot.tar.gz This one is infrastructure for verification of packages based on Release/Release.gpg. jerhard.org/files/verifydebs-snapshot.tar.gz Both are a bit underdocumented (meaning: no docs at all), so Use the Source, Luke. Hope someone will like it. I do ;-) I'm also *very* much interested in finding out what is insecurely done. It could be improved by using the Python gpgme wrapper. Any patches are *very* welcome! Bye, J PS: Yes, a crosspost, but both packages are linked (verifydebs uses python-debsigs), and both have stuff for developers and users. Flame me anyway, if you must ;-) -- Jürgen A. Erhard Invasion! http://invasion.jerhard.org I'm a FIG (http://www.fig.org) Ach, wir Paranoiker sind schon irgendwie verrückt. pgpO0TxmUDgLo.pgp Description: PGP signature
Re: [woodm@equire.com: XFree86 common]
Roland == Roland Mas [EMAIL PROTECTED] writes: Just a comment... Roland Branden Robinson (2001-08-30 21:26:18 -0500) : On Thu, Aug 30, 2001 at 09:40:03PM +0100, Jules Bean wrote: Build a fire for a man, an he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. Bwa ha, this should be my epitaph. Did you make that up yourself? It's going in my sig file. Roland I read it in a book by Terry Pratchett (Jingo). I think Roland Mr. Pratchett is original enough not to have copied that Roland elsewhere. Roland URL:http://www.co.uk.lspace.org/books/pqf/jingo.html I know that proverb(?) as Give a man fire and he will be warm for a day. Set a man on fire and he will be warm for the rest of his life. (have it in my quotes file) Don't know where I got that from, but it was surely not from Jingo (even though I love everything by pterry, I haven't read it yet). Don't know *when* I came across it, so can't say whether it was before or after Jingo came out. Bye, J PS: Yes, pterry is great, and pretty original... but I don't think he's above using a great quote when he sees one. ;-) -- Jürgen A. Erhard ([EMAIL PROTECTED], [EMAIL PROTECTED]) MARS: http://members.tripod.com/Juergen_Erhard/mars_index.html Debian GNU/Linux (http://www.debian.org) MCSE: Minesweeper Champion and Solitare Expert pgpoiOc2CGwYj.pgp Description: PGP signature
Re: NMUers: STOP BEING STUPID
Steve == Steve Greenland [EMAIL PROTECTED] writes: Steve On 23-Apr-01, 18:52 (CDT), Sean 'Shaleh' Perry Steve [EMAIL PROTECTED] wrote: This would prevent the NMUers from doing things like debhelper/debconfizing packages without the maintainer's consent, as well as keep NMU bugs down. *Violently* agree... Steve Until debhelper/debconf become required, such a substantial Steve modification should be prohibited. Until ... become required... this it *is* prohibited! No need to write it down as policy, I'd say. Bye, J PS: And I'm not even a maintainer ;-) -- Jürgen A. Erhard[EMAIL PROTECTED] phone: (GERMANY) 0721 27326 MARS: http://members.tripod.com/Juergen_Erhard/mars_index.html Perl Programmers are from Mars, Python Programmers are from Yorkshire -- Alex in c.l.py pgpisfX8qETrA.pgp Description: PGP signature
Re: RFC/ITP: everybuddy-cvs
Ben == Ben Collins [EMAIL PROTECTED] writes: Ben On Fri, Sep 01, 2000 at 04:06:33PM +, michael d. ivey wrote: I started making personal debs of the everybuddy CVS snapshots because EB releases tend to lag pretty far behind the code in CVS. I called my package ebsnap, and made it conflict with everybuddy. I put it on my site, and that was that. Now, I've adopted everybuddy and gotten through the NM process. I'd like to add the CVS version to unstable...but I don't know what to call it. My current idea is everybuddy-cvs, and make it conflict with everybuddy, and conflict/replace ebsnap, for the people who may have downloaded ebsnap. Is that the correct way to proceed? I'll be doing the rename and the upload sometime early next week. Ben Keep it the same name. Woody is unstable right now, there are Ben a lot of packages that are pre-release just for the sake of Ben testing and working out bugs. So, IMO, keep it the same name, Ben and version it appropriately. Also might add This is a CVS Ben build at the bottom of the description. Sorry, but that is *wrong*. What happens when we release and everybuddy is still not stable? Do we pull it out if it's too unstable? Why, of course we will. Which would leave our users w/o everybuddy. Or we could pull it, and replace it with the last stable... oops, the version number will be lower. So we'd need an epoch. Very bad. I've lobbied Clint Adams for doing both a zsh 3.0 and a 3.1 package. I wouldn't want to see other packages going that unstable is the greatest, fuck the users who want bulletproof stable. I think it's obvious I feel strongly about this... Ben Note, you can't break much anyway. I'm about ready to upload Ben glibc 2.1.93 (pre-2.2) to woody anyway, so if anything is Ben going to break, it's most likely going to be my fault :) Thanks for the warning. ;-) [1] as I've just now realized, he's doing three: zsh30 for the stable 3.0.x series, zsh for the devel series, and zsh-beta apparently for CVS snapshots. I'd rather have zsh be 3.0.x and zsh-unstable for 3.1.x... but I guess one can't have everything ;-) -- Jürgen A. Erhard[EMAIL PROTECTED] phone: (GERMANY) 0721 27326 MARS: http://members.tripod.com/Juergen_Erhard/mars_index.html Debian GNU/Linux (http://www.debian.org) pros do it for money -- amateurs out of love. pgpAg3MCxhT8I.pgp Description: PGP signature
Re: Python 1.6 released and GPL incompatible
Gregor == Gregor Hoffleit [EMAIL PROTECTED] writes: [...] Gregor 1) Ignore Python 1.6 and up, as long as the license is not compatible Gregorwith the GPL. That's probably the easiest way to go, but is it Gregorjustified ? Looks like a deliberate discrimination against a GregorDFSG-free license, only because it's not GPL compatible. Gregor 2) Include both Python 1.5.2 and 1.6 in woody/main. The 1.6 packages Gregorwould not satisfy the dependencies of existing packages; any maintainer Gregorwho'd make a package depend on Python 1.6 would have to make sure that Gregorits license is compatible with the Python 1.6 license. Gregor I think I'd prefer the second solution. What do others think ? Sound judgement, I'd say... and from what I gathered on c.l.py, 1.6 isn't that important anyway (they mainly did it because they promised CNRI they'd do 1.6 as a CNRI release). So, let's wait for 2.0 (final, or at least a beta with an improved license) and do that one. Bye, J -- Jürgen A. Erhard[EMAIL PROTECTED] phone: (GERMANY) 0721 27326 MARS: http://members.tripod.com/Juergen_Erhard/mars_index.html Give a man fire and he will be warm for a day. Set a man on fire and he will be warm for the rest of his life. pgpOFPIE3NwTz.pgp Description: PGP signature
Re: My recent bug's and continuing effort to debconf-ize Debian
Julian == Julian Gilbey [EMAIL PROTECTED] writes: Julian On Fri, Sep 01, 2000 at 11:34:44AM -0700, Sean 'Shaleh' Perry wrote: But then it might interrupt the installation process. Just as debconf asks all of the preinst questions before any of the packages have started unpacking, it would be nice to be able to defer any questions that *have* to wait for the postinst until the very end, when all of the packages have been installed. a) choose non-interactive and no debconf questions get asked. You can dpkg-reconfigure any package you need to [...] Julian No, this isn't what I was talking about. There was a Julian discussion recently (should I try to track down the Julian message numbers?) about some packages which could not use Julian the debconf database setup, for example because the Julian answers were too sensitive (passwords). For these, the Julian only option was to use interactive questions during the Julian postinst. I just tried less /var/lib/debconf/debconf.db and got a Permission denied. /var/lib/debconf is 700, owner root. So the passwords thing is no problem. Any others? Okay, and even if... why can't debconf have a flag don't store answer in DB? Store it somewhere the package tells us (700 owner root of course). *If* there's some *valid* reason not to store something in a *root-readable* DB, make it put it somewhere else. In the end, it *gets stored anyway. Bye, J PS: There may be packages that take a password and store it encrypted (like Zope does). But even then... (temporarily) putting it into a root-only file? Come on... PPS: I saw that discussion you're referring to, Julian... now I might have glossed over it too quickly (or I may have missed some mails), but I don't recall seeing any (good) reasons being mentioned. -- Jürgen A. Erhard[EMAIL PROTECTED] phone: (GERMANY) 0721 27326 MARS: http://members.tripod.com/Juergen_Erhard/mars_index.html Yesterday's the past and tomorrow's the future. Today is a gift -- which is why they call it the present. -- Butterfly pgplwuoSwQz42.pgp Description: PGP signature
