Re: Chao ban ve may bay
Toi can mua ve may bay di BomBay An Do xin vui long bao gia dum. Ve khu hoi.
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote: > > That's easy: you trust the Packages file to be correct when using apt, > > and it's not verified at all by per-package signatures. > In what way trust and how does that change anything? > At best you can prevent a newer version of a package to appear in the > Packages file by compromising it. You can't subvert a package itself. > But you can already ship yesterdays Release.gpg, Release and Packages > file to a user and thereby prevent any updates. > On the other hand, without package signatures ftp-master adds a > vulnerability. You can hack into it, replace debs, recreate the > Packages, Release and Release.gpg file and thereby infect users. With > signed debs that could still be detected by every user in apt-get. Only if every user is in a position to verify signatures from each Debian developer individually, which is completely unrealistic. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#283231: I have a patch to allow sudo-ldap
Quoting Paul LeoNerd Evans <[EMAIL PROTECTED]>: > I'm not too familiar with creating a source package that can create > multiple binary packages, but I have a local modification of the "sudo" > source package which creates a "sudo-ldap" binary package. This is built > using LDAP support. > > If you want I can provide this package, which I have tested on three of > my ix86-based machines. It only does very minor changes - replacing some > occurances of "sudo" with "sudo-ldap", and changing the ./configure line > in the build options. Perhaps someone with more experience could > integrate this into the main source package..? Could you send the patch, and I'll see if I can make a REAL patch the sudo maintainer can use... -- Khaddafi Iran president critical South Africa kibo Ft. Meade bomb attack domestic disruption NSA Peking Saddam Hussein counter-intelligence Cuba [See http://www.aclu.org/echelonwatch/index.html for more about this] [Or http://www.europarl.eu.int/tempcom/echelon/pdf/rapport_echelon_en.pdf] If neither of these works, try http://www.aclu.org and search for echelon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog
* Bastian Blank <[EMAIL PROTECTED]> [2005-11-24 23:45]: > On Thu, Nov 24, 2005 at 10:48:39PM +0100, Rafael Laboissiere wrote: > > Yes, I have been doing things wrongly in the past, but this is not the > > case anymore. The Changed-By fields are correct now. See, for instance, > > my last upload: > > http://lists.debian.org/debian-devel-changes/2005/11/msg01728.html > [upload of octave2.9_2.9.4-7] > > | Maintainer: Debian/IA64 Build Daemon <[EMAIL PROTECTED]> > | Changed-By: Debian Octave Group <[EMAIL PROTECTED]> Could you please explain to me why having Changed-By as a mailing list in this case (a binary NMU done by an autobuilder) is problematic? You may have good reasons for thinking Change-By should list a real person , but I fail to understand it. Notice that I am not religious about this ML versus person issue in the debian/changelog entry. If the majority of developers think we should do one way or the other, I will comply with the decision and do the necessary changes at the DOG (the Debian Octave Group, in case you did not yet get the acronym). I would like just to understand the rationale, though. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Wed, Nov 23, 2005 at 05:34:41PM +0100, Jeroen van Wolffelaar wrote: > In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). There > are 8 distinct keys used for those 525 .deb's, seven of which correspond > to DD's[1]. Slightly off the topic, but does this mean the archive contains .debs not build by Debian developers? Shouldn't sponsors be recompiling packages from non-DDs before upload? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
* Hamish Moffatt [Fri, 25 Nov 2005 20:34:02 +1100]: > On Wed, Nov 23, 2005 at 05:34:41PM +0100, Jeroen van Wolffelaar wrote: > > In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). There > > are 8 distinct keys used for those 525 .deb's, seven of which correspond > > to DD's[1]. > Slightly off the topic, but does this mean the archive contains .debs > not build by Debian developers? Shouldn't sponsors be recompiling > packages from non-DDs before upload? I was suspicious too, but it was later checked on irc that all keys actually belonged to a DD. (One of them was not in public keyservers, AIUI, and Jeroen assumed it was not a DD, or something similar.) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A lie can go round the world before the truth has got its boots on. -- Terry Pratchett -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog
On Thu, Nov 24, 2005 at 10:36:41PM +0100, Thiemo Seufer wrote: > > I can see arguments against it, but none that make > > it an RC bug. > Policy violations are RC by definition. Actually, no; policy violations are RC by *default*, but the definition of what's release-critical for a release is set by the release team with input from the developer community. I'm fairly certain that we're shipping packages in sarge that have maintainer fields pointing at people who have orphaned the packages in question; if it wasn't true at the time of the sarge release, it will certainly be true of sarge by the time etch releases. If we can survive this, I don't think that putting a mailing list address in a changelog (wrong though I think it is) would be grounds for delaying the release or removing the package from the release (the definition of RC). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Ropa Intima de Alta Calidad en CR
Si deseas desinscribirte de esta lista, envia un correo a [EMAIL PROTECTED] solicitandolo. Gracias
Re: dpkg-sig support wanted?
Hi, Anthony Towns wrote: The problem is that using gzip and ar is complicated, which adds possibilities for errors. You might find yourself not putting the deb together again and getting false signature mismatches, or worse, you might find yourself only verifying part of the .deb, and having dpkg actually use parts of the .deb that haven't been authenticated under the false conviction that you're actually safe. With "md5sum foo.deb" you know you've authenticated everything. Which is also a disadvantage in some cases. I could see a case for extending .deb files (say, with additional translations for the description and templates, thus removing the need for the maintainer to reupload new packages when new translations are ready). I think that it should be fairly easy to implement something that can verify parts of .deb files and check whether the authenticated parts together form a complete and consistent package on their own. This thread, however, is not about a technical problem, so I would propose a sauna meeting. IF this means we can switch the effort to a detached signature that is more powerful than a .changes file (or we are allowed to have multiple signatures in a .changes file), That is already possible with gnupg, just not well-documented; I'm not entirely sure what interesting breakage would occur if one were to upload a changes file with multiple signatures. and also that the .changes file will be stored in the archives along with the .debs, As it turns out, that's probably not feasible per se -- it likely implies too much inode usage, and slack space. And is probably pointless. If you don't trust the Debian infrastructure, you are free to get the source (which is signed by the maintainer) and build the package yourself. where dpkg would simply refuse per user-set policy any non-signed deb or any deb without a specific signature... I'm sorry, but you're back to the snakeoil use for deb sigs. Expecting a signature by a random Debian developer to mean something is not reasonable. That's why there can be multiple signatures. There would be one from the maintainer/buildd, a few from the Debian archive (for example, you could add one sig for "officially in Debian unstable", one for "migrated to testing" and one for "in a stable release") and if the idea of adding description/template translations later on catches on, also some from the translators/translation system. Simon signature.asc Description: OpenPGP digital signature
Re: How to deal with dependencies/conflics on third party packages
Hello Steve, Steve Langasek <[EMAIL PROTECTED]> wrote: > On Sun, Nov 20, 2005 at 11:50:55PM +, Joerg Sommer wrote: >> Steve Langasek <[EMAIL PROTECTED]> wrote: > >> > "Does not work with j2re1.3" means you should be depending on what it >> > *does* >> > work with, not trying to conflict with (unrelated) packages that don't >> > satisfy the dependency. > >> All packages in Debian they provide java-virtual-machine work with >> bootchart-view. > > That includes jamvm and gij-3.3? Yes, jamvm and gij-4.0. >> But all alternative JVMs do only work with svg output and only Sun's JVM >> support png. This is the reason, why I don't want restrict the >> dependencies upon the JVMs in Debian. > > I don't understand this explanation at all. The bug report is about a > failure due to class version mismatches; what does this have to do with svg > vs. png? I don't want block JVMs they are not in Debian, because the Debian ones are not fully functional. So I don't want to write "kaffe | sablevm | jamvm | gij" in the Dependens line, but than I get the problem of allowing old JVMs or JVMs I don't know. >> > The problem here is that bootchart-view depends on '| >> > java-virtual-machine', >> > which does not satisfy its runtime needs. Depend on something more >> > appropriate; possibly even j2re1.4. > >> I can not find this package > > The implication was that j2re1.4 would be a virtual package, provided by > those packages which implement the 1.4 spec. But of course, there's also a > *real* j2re1.4 package, not available in Debian but buildable using > java-package. > > The main point is not that j2re1.4 is the correct name to include in this > list (it may be, but I don't know that for sure); the point is that > java-virtual-machine is *incorrect*, because j-v-m only ensures you a lowest > common denominator feature set, and that's obviously not sufficient in this > case. What would be a better way? I think you get the same problem, if you force to use a C99 compiler. gcc may provide this, but other c compilers not. What would you write in the Dependens line if you need a c99. And the problem for me with java is, all JVMs in Java do not work fully with my package. Only the JVM from SUN gives you the whole functionality. Bye, Jörg. -- Alles, wovor wir Angst haben müssen, ist die Angst selbst. (Fraklin D. Roosevelt) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to deal with dependencies/conflics on third party packages
Hello sean, sean finney <[EMAIL PROTECTED]> wrote: > hi joerg, > > On Sun, Nov 20, 2005 at 10:23:58AM +, Joerg Sommer wrote: >> I've got a bug report (#336527) my package bootchart-view do not work >> with j2re1.3. But j2re1.3 is not in Debian. Can I set a conflict upon a >> packages that is not in Debian? But if it do not work with j2re1.3 it >> should more than ever not work with older version. But I would assume >> older version have different packages names. So I must add a list of >> packages names (j2re1.3 j2re1.2 j2re1.1), because I can not use the >> version clause (j2re1.3 (<< 1.3)). So what should I do? > > i'd consider simply adding a note to README.Debian/NEWS.Debian about > said problem, and being done with it altogether. maybe leave the bug > open at wishlist+wontfix for reference too, i guess. I would chose this way. I think that is the best one. Should I really decrease the level to wishlist? Is normal also alright for an wontfix bug? Bye, Jörg. -- Alles Gute wächst im Dunklen, bis es stark genug ist, ans Tageslicht zu kommen. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Wouter Verhelst <[EMAIL PROTECTED]> writes: > On Thu, Nov 24, 2005 at 06:51:24PM +0100, Goswin von Brederlow wrote: >> Wouter Verhelst <[EMAIL PROTECTED]> writes: >> > I personally see the packages in unstable as something good for >> > end-users who want to use it, or understand how the system works; but >> > for Debian's purposes, it's not optimal. >> >> So non "cabal" members should look at a different sbuild and then >> magically figure out where and how the secret one differs? What is the >> point in looking at sbuild if it isn't THE sbuild? > > It's in Debian, and it's easy to use and understand. If it doesn't > diverge too far from the sbuild actually on svn.cyberhqz.com, it's also > good enough to give you a working setup for non-debian systems. IOW, > it should be close enough to the actual thing to be useful for the > general public, but cannot be close enough to the actual thing to be > useful for official build daemons. Except it isn't working. Since a long time it wasn't able to build zsh, zsh-beta, bash3 for some unknown reason. It just deadlocks. Now its worse since the debian sbuild won't interact nicely with the wanna-build/buildd anymore due to interface changes and the binNMU feature. So now the sid sbuild only works standalone. That is a turn for the worse. >> Last year the aim was to get the buildd sbuild and debian sbuild back >> in sync and it pains me to see Ryan silently diferting it further and >> further instead of aiding that goal. > > That's one way to look at it. > > The other way would be to say that Ryan has recently been actively > working on improving the code in the wanna-build SVN, and that the > people maintaining the sbuild package in Debian (Roger?) haven't been > paying too much attention to their upstream, likely because they didn't > see the link on buildd.debian.org--a link which I, admittedly, had > missed out on at first too, because it used to point to > cvs.linux-m68k.org. There is indeed still a wanna-build CVS repository > over there, but it's been effectively unmaintained for as long as I can > remember. > > It should also be noted that Ryan, as appropriate for an Open Source > developer, is happy to review and (provided he doesn't have any > objections) apply any patches to sbuild or other things, too, as I've > been able to witness first-hand myself in the past. I wasn't looking at it as upstream and debian maintainer but more like a native package with co-maintainers. But yours is a valid point. It just pains me that Debian does not include all the software to build Debian. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Michael Banck <[EMAIL PROTECTED]> writes: > On Thu, Nov 24, 2005 at 06:44:42PM +0100, Goswin von Brederlow wrote: >> Michael Banck <[EMAIL PROTECTED]> writes: >> > On Wed, Nov 23, 2005 at 03:50:11PM +0100, Goswin von Brederlow wrote: >> >> If you NEED to do a manual binNMU it is probably best to use sbuild >> >> (the cvs, not deb) >> > >> > Patches for the Debian package are welcome, of course. >> > >> > Michael >> >> Do you know about >> >> http://svn.cyberhqz.com/svn/wanna-build/ > > Was that a question? I stated in the mail you replied to that > wanna-build is now maintained in svn. Sorry, my bad. > Still, I don't have time to look at it myself right now, so if somebody > wants to send a patch, fine, otherwise, we will get to it eventually. > Unless the release team and/or ftp-masters think this kind of new binNMU > style should be restricted to the buildds (does the old style still > work?). No. > Michael MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Michael Banck <[EMAIL PROTECTED]> writes: > On Thu, Nov 24, 2005 at 06:51:24PM +0100, Goswin von Brederlow wrote: >> Wouter Verhelst <[EMAIL PROTECTED]> writes: >> > They were, originally. Ryan's been very active on it since, and it's >> > diverged a bit from the code you're maintaining. >> >> Then he should send patches and bug reports to the debian >> package. > > When the sbuild package got orphaned two years ago or so, I asked Ryan > whether he would like to maintain it, and he said he was not interested. > Which is totally fine for me and about everybody else. > >> This split between the user/developer visible sbuild and the secret >> actual buildd is just not in the spirit of Debian. > > 1. Please drop the `secret' immediately. Unless you really want to call > http://www.debian.org/devel/buildd `secret'. That your mail got resent > with the this subject to debian-devel-announce is already stressing it > *a lot*, IMHO. The subject and initial mail is not about sbuild being secret but about the overall change for Debian. I think that one is justified. Nothing to do with this subthread. As for http://www.debian.org/devel/buildd: $ grep sbuild http://www.debian.org/devel/buildd wanna-build and calls sbuild to build the packages. http://packages.debian.org/sbuild";>sbuild This nice public page only points to the nice public sbuild debian package. There is no link to the actual sbuild used on buildds. Further the links for wanna-build and buildd (which probably indirectly included sbuild) are broken: http://m68k.debian.org/buildd/getting.html --> connection refused Did you by chance mean the wanna-build svn link on http://buildd.debian.org/? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Adeodato "=?utf-8?B?U2ltw7M=?=" <[EMAIL PROTECTED]> writes: > * Goswin von Brederlow [Thu, 24 Nov 2005 18:51:24 +0100]: > > Hi, > >> Wouter Verhelst <[EMAIL PROTECTED]> writes: > >> > They were, originally. Ryan's been very active on it since, and it's >> > diverged a bit from the code you're maintaining. > >> Then he should send patches and bug reports to the debian >> package. This split between the user/developer visible sbuild and the >> secret actual buildd is just not in the spirit of Debian. > > I believe this is wrong. In words of one of the sbuild package > co-maintainers, "the Debian package is the fork, while the sbuild in > wanna-build is upstream" [1]. And upstreams are not required forward > patches to their respective Debian maintainers, are they?; they just > make new versions publicly available, as already happens here. > > [1] http://lists.debian.org/debian-devel/2005/11/msg01463.html > > Cheers, I'm sorry for that. I didn't see sbuild as an upstream + maintainer package but as a debian package. Developed by Debian people for Debian. Aparently that was a misconception on my part. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Anthony Towns writes: > On Thu, Nov 24, 2005 at 06:28:04PM +0100, Florian Weimer wrote: > If you just want to check hashes, you should just use changes files. If > you _actually_ want to check hashes, and this isn't just a thought > experiment, working out a usable way to deliver .changes for whatever > purpose you've got in mind would be a good idea. (Again though, I don't > see a point to them, beyond reverification of the archive in the event > of an exploit. Of course, maybe that's what you want to do...) We have a perfectly useable and trivial way to deliver the hashes, which is the intresting part of the changes file for security. It is the signature in the deb. For comparison: Why do we have a signature in dsc files? From your arguments that signature is completly useless since changes files already provide all that is needed. We still sign dsc files because it is just that much easier to apt-get source foo and verify it. And that is a good thing. Why are you so set in stone against allowing the same for debs? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Steve Langasek <[EMAIL PROTECTED]> writes: > On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote: > >> > That's easy: you trust the Packages file to be correct when using apt, >> > and it's not verified at all by per-package signatures. > >> In what way trust and how does that change anything? > >> At best you can prevent a newer version of a package to appear in the >> Packages file by compromising it. You can't subvert a package itself. >> But you can already ship yesterdays Release.gpg, Release and Packages >> file to a user and thereby prevent any updates. > >> On the other hand, without package signatures ftp-master adds a >> vulnerability. You can hack into it, replace debs, recreate the >> Packages, Release and Release.gpg file and thereby infect users. With >> signed debs that could still be detected by every user in apt-get. > > Only if every user is in a position to verify signatures from each Debian > developer individually, which is completely unrealistic. Up to a point you can trust the keyring. As much as you can trust any DD signature. You try to argue that signatures are not absolutely trustworthy but that is nothing new. Nothing you can do will change that. What you fail to see (or say) is that all the security Debian already has is weak in exactly the same way. The difference to signed debs is the transparency and triviality to check. Even if that check has to use a 5 hop trust path to some DD you never met. Also for !i386 !ppc basicaly all packages are autobuild and will be signed by a handfull of people. You can go and meet them easily enough. Further, with signed debs, you could only allow installation of debs from people you trust and recompile all the rest after a source audit. If you are that paranoid. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Fri, Nov 25, 2005 at 02:38:32PM +0100, Goswin von Brederlow wrote: > Michael Banck <[EMAIL PROTECTED]> writes: > > On Thu, Nov 24, 2005 at 06:51:24PM +0100, Goswin von Brederlow wrote: > >> Wouter Verhelst <[EMAIL PROTECTED]> writes: > >> > They were, originally. Ryan's been very active on it since, and it's > >> > diverged a bit from the code you're maintaining. > >> > >> Then he should send patches and bug reports to the debian > >> package. > > > > When the sbuild package got orphaned two years ago or so, I asked Ryan > > whether he would like to maintain it, and he said he was not interested. > > Which is totally fine for me and about everybody else. > > > >> This split between the user/developer visible sbuild and the secret > >> actual buildd is just not in the spirit of Debian. > > > > 1. Please drop the `secret' immediately. Unless you really want to call > > http://www.debian.org/devel/buildd `secret'. That your mail got resent > > with the this subject to debian-devel-announce is already stressing it > > *a lot*, IMHO. > > The subject and initial mail is not about sbuild being secret but > about the overall change for Debian. I think that one is > justified. Nothing to do with this subthread. Right, these are two different things. However, the binNMU change is mostly/only useful for the release managers and buildd admins, so I fail to see why not having documented/announced it less than a week after its implementation should imply it was done in `secret', as those people are busy with the next library transition. To make this clear, I totally welcome your post documenting the new binNMU features while the authors have been too busy to do so for now. And the existance of the wanna-build/buildd/sbuild packages is not a secret, either. > As for http://www.debian.org/devel/buildd: > > $ grep sbuild http://www.debian.org/devel/buildd > wanna-build and calls sbuild to build the packages. > http://packages.debian.org/sbuild";>sbuild > > This nice public page only points to the nice public sbuild debian > package. There is no link to the actual sbuild used on buildds. > > Further the links for wanna-build and buildd (which probably > indirectly included sbuild) are broken: > > http://m68k.debian.org/buildd/getting.html --> connection refused The documentation should get fixed, then. > Did you by chance mean the wanna-build svn link on > http://buildd.debian.org/? So it is documented there as well, good. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Anthony Towns writes: > On Thu, Nov 24, 2005 at 07:47:58PM +0100, Goswin von Brederlow wrote: >> Anthony Towns writes: >> > On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote: >> >> Use 1: I have this deb in my apt-move mirror and I want to know if it >> >>was compromised on yesterdays breakin >> >> Boot a clean system with debian keyring and check all deb >> >> signatures. >> > Find some don't pass because they were signed with keys that have been >> > removed from the keyring. >> Those I remove and refetch from a clean source again. False negatives >> are no big deal. 99% of the debs will verify leaving only a >> managable amount of wokr behind. > > The "clean" source that's signed by the same key that you can't verify? If I can't find any verifiable source then the package can't be trusted and can be removed till that is changed. Still much better than having 100% untrustworthy packages. >> Ah, I see the light. >> Signatures are useless because packages have no signatures. > > That's a transitional problem, yes. In this case it's a severe one; > since there are up to 150GBs worth of .debs. It's a problem that could be > solved if it were worthwhile, but it's not worthwhile since .changes > already do everything deb sigs could do without any transition issues, > and it's not something that can be simply ignored. > > Cheers, > aj By the way, this is trivial to work around: 1) archive the Release.gpg, Release and Packages file from today 2) only allow signed debs from now on >From then on all debs can be verified. I say the transition can be simply ignored (for now). The problem will fix itself in due time when signed debs become more popular and debsign automatically adds them. At some point in the future the majority of debs will be signed and then a transition can be force by scheduling a binNMU for any remaining deb. But first there must be an official "debs may be signed" before anyone can think about a "debs MUST be signed". MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > On Thu, 24 Nov 2005, Anthony Towns wrote: >> On Thu, Nov 24, 2005 at 07:39:57AM +0100, Marc Haber wrote: >> > >Uh, packages not uploaded to the official Debian archive can do whatever >> > >they want. >> > It would, however, be convenient to be able to upload a package to >> > Debian and to be able to use the same package for different things. >> >> As far as dpkg-sign's concerned, can't you already do that by building >> the package, uploading it to debian, then running dpkg-sign? At worst >> you'd have to run dpkg-genchanges again before uploading to your other >> suite, afaics. > > You're correct. And he is also wrong. That would result in debs with the same name and version but different md5sums. Something that easily confuses apt-get and people. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Fri, Nov 25, 2005 at 02:03:12PM +0100, Goswin von Brederlow wrote: > Wouter Verhelst <[EMAIL PROTECTED]> writes: > > It's in Debian, and it's easy to use and understand. If it doesn't > > diverge too far from the sbuild actually on svn.cyberhqz.com, it's also > > good enough to give you a working setup for non-debian systems. IOW, > > it should be close enough to the actual thing to be useful for the > > general public, but cannot be close enough to the actual thing to be > > useful for official build daemons. > > Except it isn't working. Since a long time it wasn't able to build > zsh, zsh-beta, bash3 for some unknown reason. It just deadlocks. I think there's a fix for that in svn, not sure though. > Now its worse since the debian sbuild won't interact nicely with the > wanna-build/buildd anymore due to interface changes and the binNMU > feature. > > So now the sid sbuild only works standalone. That is a turn for the > worse. That's only true at this very moment. Resync with svn, done. [...] > It just pains me that Debian does not include all the software to > build Debian. Sure it does. It just doesn't include the software that Debian uses to automatically build packages, but that's not the same thing. After all, you can build packages in an automated fashion using, e.g., pbuilder; and people do actually do this all the time (where else would I have gotten those FTBFS bugs on doc-linux-nl from? That's an arch:all package). -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Simon Richter <[EMAIL PROTECTED]> writes: >>>IF this means we can switch the effort to a detached signature that is more >>>powerful than a .changes file (or we are allowed to have multiple signatures >>> in a .changes file), > > That is already possible with gnupg, just not well-documented; I'm not > entirely sure what interesting breakage would occur if one were to > upload a changes file with multiple signatures. It gives a parse error and the DAK rejects the file. >>>where dpkg would simply refuse >>>per user-set policy any non-signed deb or any deb without a specific >>>signature... > >> I'm sorry, but you're back to the snakeoil use for deb sigs. Expecting >> a signature by a random Debian developer to mean something is not >> reasonable. A signature in the deb by a random developer is as trustworthy as the changes file and you already trust that. So we are going from snakeoil to snakoil. No harm done. > That's why there can be multiple signatures. There would be one from > the maintainer/buildd, a few from the Debian archive (for example, you > could add one sig for "officially in Debian unstable", one for > "migrated to testing" and one for "in a stable release") and if the > idea of adding description/template translations later on catches on, > also some from the translators/translation system. Although that would alter the packages md5sum and even alter a package while still being in a distribution (the unstable deb would suddenly gain a signature). It would be a big change to allow this. > Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: There must be bug. But where?
Daniel Leidert <[EMAIL PROTECTED]> writes: > Am Donnerstag, den 24.11.2005, 19:53 +0100 schrieb Goswin von Brederlow: >> An incoming queue for reprepo is a ~100 lines shell script to check the >> changes file signature and include the files in reprepro. Probably less >> if you rewrite it in perl. > > Yes. But that is something, which needs to be written. debarchiver > exists and works. Or better: it normally works. > > Regards, Daniel Which reminds me that I wanted to send that shell script as whishlist bugreport to reprepro. Thanks. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Wouter Verhelst <[EMAIL PROTECTED]> writes: > On Fri, Nov 25, 2005 at 02:03:12PM +0100, Goswin von Brederlow wrote: >> It just pains me that Debian does not include all the software to >> build Debian. > > Sure it does. It just doesn't include the software that Debian uses to > automatically build packages, but that's not the same thing. Which means not all of it. > After all, you can build packages in an automated fashion using, e.g., > pbuilder; and people do actually do this all the time (where else would > I have gotten those FTBFS bugs on doc-linux-nl from? That's an arch:all > package). >From someone with sbuild setup to build arch:all packages? :))) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340606: ITP: libsub-name-perl -- Assigns a new name to referenced sub
Scripsit "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]> > This module has only one function, which is also exported by default: > subname NAME, CODEREF > Assigns a new name to referenced sub. > The name is only used for informative routines (caller, Carp, etc). Is this really useful enough to be worth the Packages.gz file space? -- Henning Makholm"*Vi vil ha wienerbrød!*" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Remove
Scripsit Chris Boyle <[EMAIL PROTECTED]> > On Thu, Nov 24, 2005 at 06:54:12PM +, paddy wrote: >> I though a robots.txt thingy on the list web archive is coming to the >> rescue ? > Huh? Isn't having the lists searchable generally a good thing? Yes, a very good thing in general. But excluding specifically the posts about c*llw*ve and d**l*ng b*nj*s might be worth a try. Of course, that is if somebody can be bothered to keep such exclusion lists up-to-date. On the other hand, l.d.o. is not the only place debian-devel is publicly archived, so it might not be worth the trouble to try to fix things locally. -- Henning Makholm "What has it got in its pocketses?" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 03:22:37PM +0100, Goswin von Brederlow wrote: > A signature in the deb by a random developer is as trustworthy as the > changes file and you already trust that. So we are going from snakeoil > to snakoil. No harm done. It's not the same, actually. A signature in a .deb needs to be made by a key which is still trustworthy at the time of verification, which could be quite some time in the future. The key which makes a .changes signature, in contrast, only *needs* to be valid at the time the upload is made -- if it is later compromised, it's not important, because by that time the archive signing key hsa taken over the role of integrity verification. Of course, using the signature on the .changes to verify the .debs independent from the archive at some later date is a nice side-benefit, but one which suffers from the same key-lifetime issues as in-deb signatures, and since the .changes from autobuilt uploads aren't publically available (apparently d-d-$arch-changes isn't archived, from info previously posted in this thread) that method of package authentication isn't going to be 100% reliable anyway. - Matt signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On 11/25/05, Matthew Palmer <[EMAIL PROTECTED]> wrote: > Of course, using the signature on the .changes to verify the .debs > independent from the archive at some later date is a nice side-benefit, but > one which suffers from the same key-lifetime issues as in-deb signatures, What exactly is this key lifetime issue? Is it a cryptographic issue? > and since the .changes from autobuilt uploads aren't publically available > (apparently d-d-$arch-changes isn't archived, from info previously posted in > this thread) that method of package authentication isn't going to be 100% > reliable anyway.
Re: Secret changes for binNMUs
Michael Banck <[EMAIL PROTECTED]> writes: > On Fri, Nov 25, 2005 at 02:38:32PM +0100, Goswin von Brederlow wrote: >> Michael Banck <[EMAIL PROTECTED]> writes: >> > On Thu, Nov 24, 2005 at 06:51:24PM +0100, Goswin von Brederlow wrote: >> >> Wouter Verhelst <[EMAIL PROTECTED]> writes: >> >> > They were, originally. Ryan's been very active on it since, and it's >> >> > diverged a bit from the code you're maintaining. >> >> >> >> Then he should send patches and bug reports to the debian >> >> package. >> > >> > When the sbuild package got orphaned two years ago or so, I asked Ryan >> > whether he would like to maintain it, and he said he was not interested. >> > Which is totally fine for me and about everybody else. >> > >> >> This split between the user/developer visible sbuild and the secret >> >> actual buildd is just not in the spirit of Debian. >> > >> > 1. Please drop the `secret' immediately. Unless you really want to call >> > http://www.debian.org/devel/buildd `secret'. That your mail got resent >> > with the this subject to debian-devel-announce is already stressing it >> > *a lot*, IMHO. >> >> The subject and initial mail is not about sbuild being secret but >> about the overall change for Debian. I think that one is >> justified. Nothing to do with this subthread. > > Right, these are two different things. However, the binNMU change is > mostly/only useful for the release managers and buildd admins, so I fail > to see why not having documented/announced it less than a week after its > implementation should imply it was done in `secret', as those people are > busy with the next library transition. To make this clear, I totally > welcome your post documenting the new binNMU features while the authors > have been too busy to do so for now. The point is that the way binNMUs are done (and accepted by DAK) was _changed_ without discussion or announcement. What should have been announced was disabling the old manual binNMU feature. The problem is that people did a binNMU and DAK refused it out of the blue. The initial mail is just to prevent that in the future. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Matthew Palmer <[EMAIL PROTECTED]> writes: > On Fri, Nov 25, 2005 at 03:22:37PM +0100, Goswin von Brederlow wrote: >> A signature in the deb by a random developer is as trustworthy as the >> changes file and you already trust that. So we are going from snakeoil >> to snakoil. No harm done. > > It's not the same, actually. A signature in a .deb needs to be made by a > key which is still trustworthy at the time of verification, which could be > quite some time in the future. The key which makes a .changes signature, in > contrast, only *needs* to be valid at the time the upload is made -- if it > is later compromised, it's not important, because by that time the archive > signing key hsa taken over the role of integrity verification. And there you have the big misconception. The archive signing key gives absolutely no integrity ensurance on the deb package. The only thing it insures is that the file was not altered _after_ leaving ftp.de.debian.org for the mirrors and/or user. In no way does it prevent altering the deb on ftp-master. The chain of trust from the DD to the enduser is broken at that point when the chnages file disapears into a non public place and the Release.gpg takes over. Even worse the Release.gpg is signed with an automatic key which I trust way less than a DDs key. > Of course, using the signature on the .changes to verify the .debs > independent from the archive at some later date is a nice side-benefit, but > one which suffers from the same key-lifetime issues as in-deb signatures, > and since the .changes from autobuilt uploads aren't publically available > (apparently d-d-$arch-changes isn't archived, from info previously posted in > this thread) that method of package authentication isn't going to be 100% > reliable anyway. > > - Matt The key-lifetime issue, as you say, is already there for the changes files. It also already there for the dsc files. The deb signatures don't change a thing there. What they change is the availability of the signature. And that they change to 100% for every signed deb (and we hope all debs gets igned at some point). MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Olaf van der Spek <[EMAIL PROTECTED]> writes: > On 11/25/05, Matthew Palmer <[EMAIL PROTECTED]> wrote: >> Of course, using the signature on the .changes to verify the .debs >> independent from the archive at some later date is a nice side-benefit, but >> one which suffers from the same key-lifetime issues as in-deb signatures, > > What exactly is this key lifetime issue? > Is it a cryptographic issue? A key can expire, get stolen / lost or get compromised and revoced. Once that happens you can't trust any signature made by that key. Although one can probably argue that an expired key still has enough trust to verify old debs. Many people don't set an expiry date anyway. While this sounds like a big problem lets have some numbers: Shortly before the sarge release we imported all source packages into the debian-amd64 DAK and actualy did have the problem with dsc file signatures. But that was a problem of maybe 20 packages (out of over 8000). Overall a miniscule problem. If I can verify all but 20 packages that realy is a great bonus. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Fri, 25 Nov 2005, Anthony Towns wrote: > (I'm amazed the security "crisis" we're having is about deb sigs > *again*, when we're still relying on md5sum which has a public exploit > available now...) Do you really want a thread about how we should switch everything to SHA-512 or something like that? > Huh? Why do you want multiple signatures of a .changes file? If I am to do with a .changes file everything I can do with the in-deb signatures, it needs to support at least nested signatures. > > and also that the .changes file will be stored in the > > archives along with the .debs, > > As it turns out, that's probably not feasible per se -- it likely implies > too much inode usage, and slack space. That speaks for in-deb signatures in the usability department. > > and that .debs with wrong/incomplete/missing > > Source: fields will be rejected (such as all automated bin-NMUed .debs made > > until about a week ago, or any made by a maintainer right now), > > Huh? I don't think #62529 is fixed yet. If you think you'll have better > luck at doing so, be my guest. That's not a prerequisite for verifying > packages from changes files though. Well, the email about the new bin-NMU structure implied that it was fixed for *NMUs done through that structure*. I very much doubt we can produce bin NMUs in our systems with the proper Source header without taking very special steps. > > > My objection is that it's *useless* for *Debian*. Debian has too many > > > sources for packages for key management to be plausible, and keeps > > This applies to .changes files too, with the aggravating addition that those > > are a bitch to find right now. > > Uh, no, .changes files are not remotely useless for Debian right now. > Where would you get that idea? I was refering to "Debian has too many sources for packages for key management to be plausible". Duh, obviously .change files are useful for Debian, DAK needs them. > The tools are the least concern; what's a few dozen lines of code here > and there matter? If you insist every package only be uploaded once, and > do the maximum packages per day, and stop all other development just to > get deb sigs done, it's roughly half a year before that's finished. New > packages, bug fixes, new upstream versions will make it take longer. Who said anything about adding in-deb sigs to the entire archive? > > where dpkg would simply refuse > > per user-set policy any non-signed deb or any deb without a specific > > signature... > > I'm sorry, but you're back to the snakeoil use for deb sigs. Expecting I see I have to spell it out completely all the time, for you will always assume you are talking to clueless people who either doesn't know anything about the issue at hand, or who will be impressed by your over-use of "snake-oil". If I want dpkg to always check a signature, it is because it is a signature I know must be there. Like an hypothetical signature added by DAK/dinstall/whatever, or a signature I add to all debs in a specific repository under my control (and in this case, with a timestamp under my own control too, which means I can use it). Doing so with signed release files is possible, but not always in the same way and under the same conditions, and it requires a lot of fragile infrastructure which would be less fragile using in-deb signatures. > a signature by a random Debian developer to mean something is not > reasonable. YOU are the one who is bringing in signatures from j.random developer. Which, I should add, is all we have in .changes files. Release files are something else, though. > I'm tempted to do something like that anyway to see if the md5sum > exploit can be used to create fire and ice .debs. Without signed debs, Make that an exploit that says "kaboom, you're it" but still runs dpkg, and I will help you with it. > you'll have no reason to trust it, which is exactly right; with signed > debs, you'll have reason to know I built it, but you won't have reason > to know I was never going to upload it to Debian because I was just > experimenting with some possible security vectors. The question is, will > you make the unwarranted assumption that because it's been built by me, > that it's usable my you? I won't, that's for sure. I might trust such a deb because it was in a archive where you place debs for general use or something else like that, but not because you signed it. > The explanation you need is "...which is useful because _". Again, I > can't see any need for multiple signatures for Debian; for non-Debian, > if deb sigs are convenient, use them. deb sigs get a lot less convenient if Debian doesn't allow them in debs uploaded to the archive. I don't really care if Debian will ever use the in-deb signatures somehow or not, but I'd like to see them allowed into the archive. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the sha
Re: dpkg-sig support wanted?
* Anthony Towns: > (I'm amazed the security "crisis" we're having is about deb sigs > *again*, when we're still relying on md5sum which has a public exploit > available now...) These exploits are irrelevant as far as the Debian archive is concerned. (And that's not because hardly any sarge user verifies the MD5 hashes, by the way. 8-) Moving away from MD5 is certainly not a bad idea, but it's not clear whether the alternatives are any better. Sure, everyone recommends SHA-256 at this stage, but nobody can give a rationale. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Remove
Henning Makholm wrote: > Scripsit Chris Boyle <[EMAIL PROTECTED]> > >>On Thu, Nov 24, 2005 at 06:54:12PM +, paddy wrote: > > >>>I though a robots.txt thingy on the list web archive is coming to the >>>rescue ? > > >>Huh? Isn't having the lists searchable generally a good thing? > > > Yes, a very good thing in general. But excluding specifically the > posts about c*llw*ve and d**l*ng b*nj*s might be worth a try. Of > course, that is if somebody can be bothered to keep such exclusion > lists up-to-date. > > On the other hand, l.d.o. is not the only place debian-devel is > publicly archived, so it might not be worth the trouble to try to > fix things locally. It's not. When querying for "Call Wave remove", the top hits are on a message from opensubscriber.com. When googling for "callwave remove" we get a page on lists.debian.org: http://lists.debian.org/debian-devel/2005/01/msg01444.html --Ken Bloom -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Blrgh!
OK. So I was working on the problem of fixing dpkg-dev so that
foo Depends: foo-data {SourceVersion}, foo-libs {BinaryVersion}
or something similar actually works. By parsing the version numbers.
Now it's apparently been changed under our noses, in such a way that my
proposed
scheme won't work -- and furthermore anyone who implemented their own
version
of such code, in their own package, will find it magically broken.
Thanks to Goswin and Henrique for *notifying* people of this, since
apparently whoever changed it didn't think about the impacts on other
developers.
Instead binNMU versions are now made by adding +b1 (+b2, +b3) to the
version and containing a "Source: foo (non-NMU version)" line. The
later makes it possible to reliable associate binNMUs with their
source.
So how do we write a package Depends: line now? Apparently the buildd uses
the original source,
and adds a changelog entry -- *but what happens to the {SourceVersion}
substitution?* Does the buildd
alter the substvars file before compiling? Does the {SourceVersion}
substitution end up being the original 1.2-3 source version, or the 1.2-3+b4
version? Whichever it ends up being, *how do we get the other one* if we
need it?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Anthony Towns writes: > .deb signatures are aimed at giving users some sort of assurance the > package is "valid"; but when you actually look into it -- at least in > Debian's circumstances -- those signatures can't actually give any > meaningful assurance for any specific validity. Don't they give the user the assurance that a Debian developer was responsible for building and providing the package? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > The archive signing key gives absolutely no integrity ensurance on the > deb package. The only thing it insures is that the file was not > altered _after_ leaving ftp.de.debian.org for the mirrors and/or > user. In no way does it prevent altering the deb on ftp-master. Isn't that a useful assurance? Perhaps I trust the maintenance of ftp-master, but not the maintenance of Joe Random Mirror. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340778: ITP: me-jasspa -- A lightweight but fully featured editor
Package: wnpp Severity: wishlist Owner: Patrick Das Gupta <[EMAIL PROTECTED]> * Package name: me-jasspa Version : 20050505 Upstream Author : Jon Green * URL : http://www.jasspa.com/ * License : GPL Description : A lightweight but fully featured editor Jasspa's MicroEmacs is an emacs-like editor with various features: * Window manager support for the X Window System. * Integrated spell checker. * Undo facility to back-step changes. * Extensive macro language allowing new commands to be created. * Auto C indentation support, with user definable indentation schemes for other languages. * Auto saving and automatic multiple backups. * Multi-buffer support. * Multi-task pipe support for executing shell commands within the context of the editor. * Color language hi-lighting, can be used for any type of file. * Comprehensive on-line help. * Abbreviation and command completion. * Binary file editing support. * Integral file browser with FTP support. * Session history. * Extensible, menu and dialogue features. Homepage: http://www.jasspa.com/ -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.14.2 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 03:13:58PM +0100, Goswin von Brederlow wrote: > > You're correct. > And he is also wrong. > That would result in debs with the same name and version but different > md5sums. Something that easily confuses apt-get and people. And yet, somehow people manage partial cross-grades between Debian and Ubuntu... Regards, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 12:49:11PM -0800, Thomas Bushnell BSG wrote: > Anthony Towns writes: > > .deb signatures are aimed at giving users some sort of assurance the > > package is "valid"; but when you actually look into it -- at least in > > Debian's circumstances -- those signatures can't actually give any > > meaningful assurance for any specific validity. > Don't they give the user the assurance that a Debian developer was > responsible for building and providing the package? Not really, they give the assurance that it was built by someone who at some point possessed a key that at some point was considered sufficient to identify a Debian developer or a buildd. What assurance would you take from a package signed by Chip's old key? (And why do you think it's actually helpful? Debian developers build *lots* of crap, especially if you can't differentiate stuff uploaded to Debian and not) Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 02:27:23PM -0200, Henrique de Moraes Holschuh wrote: > Well, the email about the new bin-NMU structure implied that it was fixed > for *NMUs done through that structure*. Then the email was wrong. *shrug* > > > > My objection is that it's *useless* for *Debian*. Debian has too many > > > > sources for packages for key management to be plausible, and keeps > > > This applies to .changes files too, with the aggravating addition that > > > those > > > are a bitch to find right now. > > Uh, no, .changes files are not remotely useless for Debian right now. > > Where would you get that idea? > I was refering to "Debian has too many sources for packages for key > management to be plausible". Duh, obviously .change files are useful for > Debian, DAK needs them. Then my comment doesn't "appl[y] to .changes files too". > > The tools are the least concern; what's a few dozen lines of code here > > and there matter? If you insist every package only be uploaded once, and > > do the maximum packages per day, and stop all other development just to > > get deb sigs done, it's roughly half a year before that's finished. New > > packages, bug fixes, new upstream versions will make it take longer. > Who said anything about adding in-deb sigs to the entire archive? If they provide a useful service, then of course they should be everywhere. If they don't provide a useful service, why should they be anywhere? The dak check, for reference, is the one that authenticates an ar's in the correct form, it's not an explicit "we had dpkg-sig" check. > If I want dpkg to always check a signature, it is because it is a signature > I know must be there. Like an hypothetical signature added by > DAK/dinstall/whatever, or a signature I add to all debs in a specific > repository under my control (and in this case, with a timestamp under my own > control too, which means I can use it). Again, what you do in your own repositories is _fine_. .deb signatures are a completely useful thing to do in some circumstances; which I'm inclined to classify as "private development / public release". Debian just happens not to be in that problem space. > > a signature by a random Debian developer to mean something is not > > reasonable. > YOU are the one who is bringing in signatures from j.random developer. Uh, no, it's what this thread's about. You know, random developers uploading signed packages to the archive...? > > I'm tempted to do something like that anyway to see if the md5sum > > exploit can be used to create fire and ice .debs. Without signed debs, > Make that an exploit that says "kaboom, you're it" but still runs dpkg, and > I will help you with it. ATM I've got better things to do. But xmas is coming up, with the corresponding need for a pointless xmas project... > > The explanation you need is "...which is useful because _". Again, I > > can't see any need for multiple signatures for Debian; for non-Debian, > > if deb sigs are convenient, use them. > deb sigs get a lot less convenient if Debian doesn't allow them in debs > uploaded to the archive. How so? Seriously -- add the signature after uploading to Debian. At worst, if you have a deb that's in both Debian and some other source, you might end up installing the unsigned .deb from Debian instead of the signed version -- but you've still verified it just like every other Debian package, so... big deal? If you set up apt's pinning correctly, that won't even happen. Cheers, aj signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 07:59:40PM +0100, Florian Weimer wrote: > * Anthony Towns: > > (I'm amazed the security "crisis" we're having is about deb sigs > > *again*, when we're still relying on md5sum which has a public exploit > > available now...) > These exploits are irrelevant as far as the Debian archive is > concerned. (And that's not because hardly any sarge user verifies the > MD5 hashes, by the way. 8-) Uh. You're seriously putting your reputation on that claim? And md5 hashes have been verified since either slink or potato depending on when you started using apt; possibly earlier if dselect methods used them like they should have. debootstrap certainly verified them for woody. And heck, they've been used in .changes since day 0. > Moving away from MD5 is certainly not a bad idea, but it's not clear > whether the alternatives are any better. Sure, everyone recommends > SHA-256 at this stage, but nobody can give a rationale. MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or higher) are significantly harder to break in practice, and there's nothing better yet. Cheers, aj signature.asc Description: Digital signature
Re: Remove
Ken Bloom wrote: Henning Makholm wrote: Scripsit Chris Boyle <[EMAIL PROTECTED]> On Thu, Nov 24, 2005 at 06:54:12PM +, paddy wrote: I though a robots.txt thingy on the list web archive is coming to the rescue ? Huh? Isn't having the lists searchable generally a good thing? Yes, a very good thing in general. But excluding specifically the posts about c*llw*ve and d**l*ng b*nj*s might be worth a try. Of course, that is if somebody can be bothered to keep such exclusion lists up-to-date. On the other hand, l.d.o. is not the only place debian-devel is publicly archived, so it might not be worth the trouble to try to fix things locally. It's not. When querying for "Call Wave remove", the top hits are on a message from opensubscriber.com. When googling for "callwave remove" we get a page on lists.debian.org: --Ken Bloom And now you're perpetuating the trend, since you have that link next to the keyword. Suggestion: Why don't all the readers of debian-devel put something like this on their blogs: Google has a tendency for improperly indexed items to stay that way. In order to fix this, it is neccessary to create a "google bomb" by having several sites all create a link to the correct page with the keyword. In order to fix an incorrect entry that causes spam to the debian-devel mailinglist, I want everyone to know that you should go here to _remove callwave_ [0]. Cheers, Benjamin [0] http://www.callwave.com/members/help/help.asp?item=SEARCH_cancel signature.asc Description: OpenPGP digital signature
Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog
On Fri, Nov 25, 2005 at 09:01:24AM +0100, Rafael Laboissiere wrote: > * Bastian Blank <[EMAIL PROTECTED]> [2005-11-24 23:45]: > > | Maintainer: Debian/IA64 Build Daemon <[EMAIL PROTECTED]> > > | Changed-By: Debian Octave Group <[EMAIL PROTECTED]> > > Could you please explain to me why having Changed-By as a mailing list in > this case (a binary NMU done by an autobuilder) is problematic? You may > have good reasons for thinking Change-By should list a real person , but > I fail to understand it. Please explain we the meaning of "person". Bastian -- I object to intellect without discipline; I object to power without constructive purpose. -- Spock, "The Squire of Gothos", stardate 2124.5
Re: dpkg-sig support wanted?
On Sat, Nov 26, 2005 at 08:48:45AM +1000, Anthony Towns wrote: > On Fri, Nov 25, 2005 at 03:13:58PM +0100, Goswin von Brederlow wrote: > > > You're correct. > > And he is also wrong. > > That would result in debs with the same name and version but different > > md5sums. Something that easily confuses apt-get and people. > > And yet, somehow people manage partial cross-grades between Debian and > Ubuntu... People manage to do it, but it really isn't a good idea at all to mix repositories which contain different builds of the same source packages. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Sat, Nov 26, 2005 at 09:13:02AM +1000, Anthony Towns wrote: >> Moving away from MD5 is certainly not a bad idea, but it's not clear >> whether the alternatives are any better. Sure, everyone recommends >> SHA-256 at this stage, but nobody can give a rationale. > MD5 is broken; SHA-1 is where MD5 was a couple of years ago, SHA256 (or > higher) are significantly harder to break in practice, and there's > nothing better yet. Just a comment here for those who are not used to hash functions: "Broken" here means that you can generate collisions faster than using the birthday attack (2^64 for MD5, 2^80 for SHA-1). It does not have to mean that you can do _really_ evil stuff, like generate a second file with the same MD5 hash as a given file (so-called "second preimage", IIRC) and to the best of my knowledge, nobody has done so yet). However, there's a long way from "you can't generate a valid .deb with a given md5sum easily" to "SHA-256 is no better than MD5". You can generate an MD5 collision in four hours on a standard desktop computer today; you're nowhere near that for SHA-1, and SHA-256 is still AFAIK not broken (although it relies on the same basic structure as MD5 and SHA-1). All three might eventually be truly broken, but you can bet that MD5 will be the first to go. If you use SHA-256 today instead of MD5, you probably buy yourself a few extra years, which you can use to smooth out the transition to the next hash function when the world advances. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
> "Thiemo" == Thiemo Seufer <[EMAIL PROTECTED]> writes: >> Well, even if I know naught about it, it looks to me that having >> something signed is better than having the same something not signed. Thiemo> Sorry, but that's a snake oil rationale. A: Why do you lock your car up[1]? B: Because it looks like having it locked is better then not having it locked. A: Sorry, but that's a snake oil rationale. Anybody can pick the lock and break in. Anybody can smash a window and break in. etc. However, we still lock our cars regardless. We still lock our houses. We still use signatures and ID cards (all of which can be forged) as protection to keep our money safe. The reason why? Because we have just made it more difficult (or so we hope!) for somebody to break in. We still consider this a worth while compared with the added inconvenience of having to maintain the additional security (e.g. keep the key safe and not lost). Despite the fact we all know it is not absolute security. It is also feasible. Yes, you could hire a security guard to watch your car 24 hours a day, but that is likely to cost more then the car is worth. Most people don't consider their cars to be this important. I think the same thing applies here - sure somebody could interfere with the system and either steal the private key or get a package signed that shouldn't be signed, but if you really want to argue along these lines, I think we remove all signatures everywhere, because the possibility exists any one of these could be "forged" (especially as Debian cannot guarantee that every maintainer keeps their private key secure, and that their build systems are secure, etc). So just saying "its snake oil" isn't really saying anything IMHO, because taken to an extreme all security we have in this world *is* snake oil. Sometimes it works. Sometimes it doesn't work. That doesn't mean we shouldn't try to improve it as much as possible. The only exception I would make is when "improvements" mean extra "security" for political/red tape reasons which do nothing to stop the weaknesses they are meant to stop, but instead serve to make our politicians looks good as well as giving them more income. However, I think the ability to trace a Debian binary package to its source, even if the original .changes file is no longer available, is a definite advantage, and is not any less reliable or secure then using the original .changes file for the same purpose. In fact, you could argue it is more secure then the "Received" headers everyone relies on to trace SPAM (which have no cryptographic signature). I also believe that the threat of somebody being tricked into installing a Trojan package is a very real possibility, and we should do everything we can do to aid our users prevent this from happening. Notes: [1] Assuming you have a car, if not replace the words "car" and "lock" with something more appropriate. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Sat, Nov 26, 2005 at 10:47:57AM +1100, Brian May wrote: >>> Well, even if I know naught about it, it looks to me that having >>> something signed is better than having the same something not signed. >> Sorry, but that's a snake oil rationale. > A: Why do you lock your car up[1]? Because it makes it harder to steal the car. I think the point was that signing a .deb did not automatically make it harder to do whatever the scenario asked for. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Fri, 25 Nov 2005, Nathanael Nerode wrote:
> OK. So I was working on the problem of fixing dpkg-dev so that
>
> foo Depends: foo-data {SourceVersion}, foo-libs {BinaryVersion}
>
> or something similar actually works. By parsing the version numbers.
I'd very much like debhelper or dpkg-* to give us another variable that
points to the parent version [changelog-wise] when bin NMUs are done, and to
the current version [changelog-wise] otherwise.
Meanwhile, I am using this: unversioned depends and two conflicts: (<<
{Upstream-Version}), (>= {Upstream-Version}.1).
BinNMUs won't break compatibility between arch any and arch all in any of my
packages, and debian revisions breaking them are rare enough that I will
track that by hand, so the above is enough (although far from ideal).
> So how do we write a package Depends: line now? Apparently the buildd uses
> the original source,
See above. We had that problem already, but now we will have to deploy a
real solution instead of hacks. Ain't that nice? :-)
Does anyone have any idea on how to detect if a currently running buind is a
bin NMU or not?
> and adds a changelog entry -- *but what happens to the {SourceVersion}
> substitution?* Does the buildd
> alter the substvars file before compiling? Does the {SourceVersion}
I bet it works in the simplest way possible, i.e. it is set to the latest
changelog entry: the binNMU version.
> substitution end up being the original 1.2-3 source version, or the
> 1.2-3+b4 version? Whichever it ends up being, *how do we get the other
> one* if we need it?
We really need another substvar with different semantics.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Heimdal autotools dramas
My biggest concern with the Heimdal in experimental, is glob() in libroken. To the best of my knowledge, it isn't required because libc6 glob() does everything required. I am concerned, because of the potential of the symbols conflicting with the function in libc6. The Heimdal configure script correctly detects that glob() is present in libc6, but appears to build glob.c anyway, and it also installs glob.h. A similar situation appears to exist with fnmatch, but I haven't investigated in detail. Unfortunately, solving this is pushing my automake knowledge to its limits. lib/roken/Makefile.am has: if have_glob_h glob_h = else glob_h = glob.h endif Some how that is being set in lib/roken/Makefile, despite the fact have_glob_h is also set (this is confusing me!!!) I simply cannot see where lib/roken/Makefile.am references glob.c. However, lib/roken/Makefile references glob$U.lo and glob$U.o. I asked upstream Heimdal and got no response. Any help would be much appreciated. Thanks. PS. Source code is Heimdal in Debian experimental. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 02:57:36PM +0100, Goswin von Brederlow wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote: > >> > That's easy: you trust the Packages file to be correct when using apt, > >> > and it's not verified at all by per-package signatures. > >> In what way trust and how does that change anything? > >> At best you can prevent a newer version of a package to appear in the > >> Packages file by compromising it. You can't subvert a package itself. > >> But you can already ship yesterdays Release.gpg, Release and Packages > >> file to a user and thereby prevent any updates. > >> On the other hand, without package signatures ftp-master adds a > >> vulnerability. You can hack into it, replace debs, recreate the > >> Packages, Release and Release.gpg file and thereby infect users. With > >> signed debs that could still be detected by every user in apt-get. > > Only if every user is in a position to verify signatures from each Debian > > developer individually, which is completely unrealistic. > Up to a point you can trust the keyring. As much as you can trust any > DD signature. You try to argue that signatures are not absolutely > trustworthy but that is nothing new. I'm arguing that a 5-hop-long signature chain to establish the validity of a Debian package is as good as useless, and worse if the user doesn't understand this. And a 5-hop-long signature chain does *not* mean that anyone in that chain trusts the person holding the key on the end to upload packages to Debian. The only thing we have that establishes *that* is the presence of the user's key in the Debian keyring, so then you have the logistical problem of how arbitrary users are supposed to verify whether a given key is in the keyring. The debian-keyring package doesn't get updated every time there's a key added or removed, and the web interface to keyring.debian.org doesn't provide any cryptographic assurances. Oh, and BTW, check the IPs of ftp-master.debian.org and keyring.debian.org... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
up-to-date debian keyring with rsync (Re: dpkg-sig support wanted?)
* Steve Langasek [Fri, 25 Nov 2005 17:19:01 -0800]: > how arbitrary users are supposed to verify whether a given key is in the > keyring. The debian-keyring package doesn't get updated every time there's > a key added or removed, and the web interface to keyring.debian.org doesn't > provide any cryptographic assurances. Just as a side note other developers may be interested in knowing, the debian keyring can be synced via rsync. I personally like having a mostly-up-to-date copy of it in my computer. % cat /etc/cron.weekly/LOCAL-update-keyring #! /bin/sh -e cd /var/local/keyring rsync -rlptDq rsync://keyring.debian.org/keyrings/ . -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Elton John - Too many tears -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Brian May wrote: > > "Thiemo" == Thiemo Seufer <[EMAIL PROTECTED]> writes: > > >> Well, even if I know naught about it, it looks to me that having > >> something signed is better than having the same something not signed. > > Thiemo> Sorry, but that's a snake oil rationale. > > A: Why do you lock your car up[1]? > > B: Because it looks like having it locked is better then not having it > locked. > > A: Sorry, but that's a snake oil rationale. Anybody can pick the lock > and break in. Anybody can smash a window and break in. etc. Wrong, it makes break-ins harder. OTOH we don't put stickers with "this car is locked" on our cars. The quote above suggested a signed package is somehow better than an unsigned one, even when no improvements can be shown. But the only thing it reliably achieves in that case is to increase the exposure of the signing key. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Primer sitio web de Ropa Intima en Costa Rica
Si deseas desinscribirte de esta lista, envia un correo a [EMAIL PROTECTED] solicitandolo. Gracias
Bug#340805: ITP: gearhead -- roguelike mecha role playing game
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: gearhead Version : 1.000 Upstream Author : Joseph Hewitt <[EMAIL PROTECTED]> * URL : http://www.geocities.com/pyrrho12/programming/gearhead/ * License : LGPL Description : roguelike mecha role playing game A century and a half ago the Earth was nearly destroyed by nuclear war. Now, a federation of free city-states has begun to restore civilization. However, there are forces operating in the darkness which will unleash the horrors of the past age in a bid to determine the future of the human race. Features of the game include random storyline generation, richly detailed character generation, complex NPC interaction, and of course over 150 different mechanical designs ranging from jet fighters to giant robots to city-smashing tanks. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 05:19:01PM -0800, Steve Langasek wrote: > Oh, and BTW, check the IPs of ftp-master.debian.org and > keyring.debian.org... Well, at this moment those are distinct, because ftp-master is temporarily hosted on spohr.debian.org, and not on raff.debian.org, where keyring.d.o still is. But yes, they used to be the same and will again become the same. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
[Steinar H. Gunderson] > All three might eventually be truly broken, but you can bet that MD5 > will be the first to go. If you use SHA-256 today instead of MD5, you > probably buy yourself a few extra years, which you can use to smooth > out the transition to the next hash function when the world advances. You may laugh if you wish, but I think it's annoying to have to move to a hash function whose hexadecimal representation takes 64 bytes, which doesn't leave much room on an 80-column line to describe what the hash is hashing. Maybe by the time coreutils ships a sha256sum program, the world will have settled upon BASE64, which requires only 43 bytes. signature.asc Description: Digital signature
