Re: package management symlink
Sören Reinecke writes: > Dear Debian mailing list community, > > I am Sören alias Valor Naram and I founded the project "goeasyLinux". I will > help to make linux more user friendly. > > A short introduction to "goeasyLinux" can be found at > https://github.com/ValorNaram/goeasylinux/blob/master/README.md > > The specification I wrote in order to make a cross platform symlink to > package management systems: > https://github.com/ValorNaram/goeasylinux/blob/master/package%20management/package%20install.md I appreciate your efforts and idea of having a common package management system across all/most linux distributions. I took a look at your git repository above. And I realized there are already a few package managers which work similar to your idea. Take a look at `pkcon` provided by `packagekit-tools` in Debian. It is also present in various other linux distributions, I have used it on a few other distributions including Fedora, Gentoo and even on my phone's Sailfish OS. since pkcon does already what you are trying to achieve here, and is also very matured in terms of functionality that it provides. You seem to be just re-inventing the wheel. > > With your help I want to make package installing/removing equal on all linux > systems without disturbing the diversity we have across linux distributions. > In order to do that we need just a symlink, no replacement of existing > software. > > > Best wishes > > Sören alias Valor Naram
Re: package management symlink
Sören please see: https://xkcd.com/927/ /Andy On 05/02/2019 06:20, Sören Reinecke wrote: Dear Debian mailing list community, I am Sören alias Valor Naram and I founded the project "goeasyLinux". I will help to make linux more user friendly. A short introduction to "goeasyLinux" can be found at https://github.com/ValorNaram/goeasylinux/blob/master/README.md The specification I wrote in order to make a cross platform symlink to package management systems: https://github.com/ValorNaram/goeasylinux/blob/master/package%20management/package%20install.md With your help I want to make package installing/removing equal on all linux systems without disturbing the diversity we have across linux distributions. In order to do that we need just a symlink, no replacement of existing software. Best wishes Sören alias Valor Naram --- This email has been checked for viruses by AVG. https://www.avg.com
Re: package management symlink
Am Di., 5. Feb. 2019 um 12:03 Uhr schrieb Ansgar : > > Sören Reinecke writes: > >> I'm not convinced that having to remember different package manager > >> names is a significant problem for new people adopting a Linux > >> distribution. The name is a very small part of the > >> differences between > >> the package managers (they have very different > >> behaviour models, not > >> just names), and the package managers are a small part of all the > >> differences between distributions. > > > > Many developers don't provide their software via a repository instead > > they provide the source code with an INSTALL file. They depend on > > dependencies they resolve through the repositories. Approving "nimue" > > just as symlink that points to the package management system across > > linux systems would enable them to write just one install script for > > debian and red hat systems for example. > > No, that already stops working when package are named differently which > is frequently the case. There is no readline-devel package in Debian > and no libreadline-dev in Red Had or Gentoo. > [...] Additionally to what Ansgar already said, we already have had PackageKit for ages. Just use the `pkcon` tool to trigger package installations in a distribution-agnostic way - if you know the names of the packages you want to install for each distribution, of course. (for applications and very few software components, AppStream can jump in as a distro-agnostic way to install software via `appstreamcli install `. Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
Re: package management symlink
Sören Reinecke writes: >> I'm not convinced that having to remember different package manager >> names is a significant problem for new people adopting a Linux >> distribution. The name is a very small part of the >> differences between >> the package managers (they have very different >> behaviour models, not >> just names), and the package managers are a small part of all the >> differences between distributions. > > Many developers don't provide their software via a repository instead > they provide the source code with an INSTALL file. They depend on > dependencies they resolve through the repositories. Approving "nimue" > just as symlink that points to the package management system across > linux systems would enable them to write just one install script for > debian and red hat systems for example. No, that already stops working when package are named differently which is frequently the case. There is no readline-devel package in Debian and no libreadline-dev in Red Had or Gentoo. Also what you suggest already exists, for example in the form of "pacapt" (but there are alternatives too!). What is the benefit of adding yet another version of these scripts? Ansgar
Re: package management symlink
On Tue, Feb 05, 2019 at 07:22:21AM +, Jonathan Dowland wrote: > You need to create a Debian package that contains your symlink (or bash > script), and then either find someone to sponsor uploads of your package > into Debian, or become a Debian Maintainer or Developer to do so > yourself. > > You can start reading about this stuff here: > https://www.debian.org/devel/join/newmaint Note that this page is for DD candidates while the link for people wanting to maintain packages is https://mentors.debian.net/intro-maintainers -- WBR, wRAR signature.asc Description: PGP signature
Re: package management symlink
On Tue, Feb 05, 2019 at 07:20:23AM +0100, Sören Reinecke wrote: With your help I want to make package installing/removing equal on all linux systems without disturbing the diversity we have across linux distributions. In order to do that we need just a symlink, no replacement of existing software. You need to create a Debian package that contains your symlink (or bash script), and then either find someone to sponsor uploads of your package into Debian, or become a Debian Maintainer or Developer to do so yourself. You can start reading about this stuff here: https://www.debian.org/devel/join/newmaint You are probably out of time to do this in time for the next Debian release, because our freeze for that release begins at the end of this month. That's the *how*: a short sentence on whether you *should*: reading the page you provide, I don't think it's a good idea to actually do this. I'm not convinced that having to remember different package manager names is a significant problem for new people adopting a Linux distribution. The name is a very small part of the differences between the package managers (they have very different behaviour models, not just names), and the package managers are a small part of all the differences between distributions. That said, if you want to pursue this, the route above is how to do it. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Color Management in Debian
Hi Till, and thanks for your message. First, I think that this type of communication between Debian and its derivatives (and reversely in that case) is very important for the health of our ecosystem. So thank you for this. Le mardi, 31 mai 2011 16.16:18, Till Kamppeter a écrit : What is needed is to introduce some new packages, especially colord, update other packages, build packages against colord, ... This would be perhaps much easier when Debian would add the same color management stack and also if we want to follow the plans to have a unique printing stack in Debian and Ubuntu. This sounds like a very worthwhile goal. What has to be done is to fix all the Related bugs (which are more feature requests than bugs) on the Blueprint linked above also for Debian. Especially colord needs to get packaged first: https://bugs.launchpad.net/ubuntu/+bug/741448 and then all the other packages built with colord being present. Given that Debian is currently not frozen (and that the Oneiric release will very probably happen before Wheezy's), I really think that not uploading those packages to Debian first would be a shame, as this would only mean doubling efforts. So I suggest we group people interested from Debian and Ubuntu (and any other derivatives fwiw) in a single place [0] and start working towards getting those packages to Debian first. With the NEW delays[1] these days, a sync from Debian to Ubuntu could happen in a few days; I don't think this is a serious limit. As for the common place, my personal preference would be an alioth group (pkg- colormgmt ?), with git-based packaging; but this should by no means hinder other proposals [2]. So despite my limited knowledge in this area, I would be happy to help getting those packages to Debian, by reviewing and eventually upload packages. Cheers, OdyX [0] debian-printing@l.d.o /could/ be that place, but I'm not certain it's within it's scope. [1] For which the FTP-Masters team is to be thanked for their awesome job ! [2] Who knows, we could even imagine using bazaar! signature.asc Description: This is a digitally signed message part.
Re: Color Management in Debian
Still keeping Till on CC (just a warning for new readers of this thread). On Mié 01 Jun 2011 10:00:17 Didier Raboud escribió: [snip] So despite my limited knowledge in this area, I would be happy to help getting those packages to Debian, by reviewing and eventually upload packages. +1 to what Odyx said, and I'm also willing to try to be helpfull in this area. -- Cuando tenga duda, utilice la solución mas simple. Principio de William Occam, también llamado la navaja de Occam Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Color Management in Debian
Hi Till! on the Ubuntu Developer Summit this month we discussed the introduction of color management in Ubuntu. See https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-icc-color-management That is great, colour mnanagement is still one of the missing pieces which should be taken care of as soon as possible imho. Unfortunately I'm swamped with work so I want have the time to help and discuss, but if you need a sponsor for packages don't hesitate to ask. Cheers and thanks for your work, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4de5032a.8010...@bzed.de
Re: Color Management in Debian
If you start discussing, can you CC me, as I am not subscribed to this list. Thanks. Till On 05/31/2011 04:16 PM, Till Kamppeter wrote: Hi, on the Ubuntu Developer Summit this month we discussed the introduction of color management in Ubuntu. See https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-icc-color-management What is needed is to introduce some new packages, especially colord, update other packages, build packages against colord, ... This would be perhaps much easier when Debian would add the same color management stack and also if we want to follow the plans to have a unique printing stack in Debian and Ubuntu. Therefore I want to ask you all whether you would like to cooperate. What has to be done is to fix all the Related bugs (which are more feature requests than bugs) on the Blueprint linked above also for Debian. Especially colord needs to get packaged first: https://bugs.launchpad.net/ubuntu/+bug/741448 and then all the other packages built with colord being present. Anyone wants to volunteer? Till -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4de50054.6020...@gmail.com
Re: Package management unsafe?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steinar H. Gunderson wrote: http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html What are people's thoughts on this? It's been known for quite a while. (I asked one of the guys publishing it, and he was fully aware of that, but felt it was still important to bring light to it.) I'm the researcher that Steinar exchanged emails with. I just wanted to clarify this a bit as I believe he misunderstood something I said the other week. -- Sorry for any confusion, Steinar. These types of attacks, replay attacks[1] and endless data attacks[2], were well-known in general, but not with respect to APT or other package managers being vulnerable to them. We by no means are claiming to have discovered replay attacks, nor are we aware of previous widespread disclosure that package managers are vulnerable to these attacks. A big thank you to the various Debian security people who have helped answer questions and verify information for us recently. I believe most of the issues we disclosed are in discussion and will be addressed. [1] http://en.wikipedia.org/wiki/Replay_attack [2] http://insecure.org/stf/wietse_murphy.html - -- Justin Samuel https://www.cs.arizona.edu/~jsamuel/ gpg: 0xDDF1F3EE [66EF 84E2 F184 B140 712B 55A7 2B96 AB8F DDF1 F3EE] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIiUXsK5arj93x8+4RApbRAKCrdycZYMjKIVb8F1KLWh/mSoSL/wCgsVba +TqRksohzfEUEUL9Tiy8wn0= =Y0nc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
On Fri, Jul 11, 2008 at 07:36:44AM -0500, Ron Johnson [EMAIL PROTECTED] was heard to say: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html What are people's thoughts on this? I don't see anything new or surprising on that page. In fact, the two attacks they list (replaying old versions of an archive and taking over a mirror) were discussed at the time that archive signing was added to apt. My recollection is that the conclusion regarding replay attacks was that it wasn't clear how signing archives would prevent this (you would presumably need to somehow periodically change the archive signature, and warn the user if it was out of date). Mirror takeovers are, of course, exactly why archive signing was added to apt. I'm talking now about their use to provide unsigned and faulty packages, not to delay updates (which is just a replay attack). It's not clear whether archive signing will actually defend against this attack *in practice*; some users seem to investigate bad signatures, but I'm sure a lot just override the warning, especially because there are an unfortunately high number of false positives. But the technology itself can detect this situation. When I saw the headline I figured he was talking about actual code vulnerabilities in package managers (e.g., buffer overflows parsing the Packages file); that would be a lot more interesting and worrying. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
On Sun, 2008-07-13 at 02:13 +0200, Franklin PIAT wrote: Hello, On Sat, 2008-07-12 at 23:13 +, Joe Smith wrote: Andrei Popescu andreimpopescu at gmail.com writes: One costly solution would be to get the client the send a challenge to a trusted server, which would respond by gpg-signed the challenge + the checksum of current .Release file. How would all these schemes work with offline mirrors? eg, ones that are built, and used without an internet connection for a month. kk Franklin -- Karl Goetz [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Package management unsafe?
On Sun, 2008-07-13 at 16:19 +0930, Karl Goetz wrote: On Sun, 2008-07-13 at 02:13 +0200, Franklin PIAT wrote: Hello, On Sat, 2008-07-12 at 23:13 +, Joe Smith wrote: Andrei Popescu andreimpopescu at gmail.com writes: One costly solution would be to get the client the send a challenge to a trusted server, which would respond by gpg-signed the challenge + the checksum of current .Release file. How would all these schemes work with offline mirrors? eg, ones that are built, and used without an internet connection for a month. You would be warned that your security update server can't be contacted/validated, which is accurate. BTW, of course, the GPG wouldn't have to be Debian key, but any trusted key for that purpose (e.g including corporate, Debian derivative key). Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
Florian Weimer fw at deneb.enyo.de writes: * Ron Johnson: http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html What are people's thoughts on this? HTTPS doesn't help against non-trusted mirrors. The difficult question is how to tell an APT source which is not updated regularly from an APT source that has been rolled back in a replay attack. Actually the attack works just fine without rolling back for a replay attack. I have my mirror stop updating. If I can assume that most clients use only my mirror, and not others, then once a major security flaw comes out in a package version my mirror uses, then I have a list of IP addresses (from my server logs) that may be exploitable. So there is no reason to differentiate between a stale mirror and a potential attack mirror. Any mirror more than say 7-days out of date should be considered potentially unsafe, and the user should be warned that the mirror is stale, which may be an attack attempt, and that they should consider choosing a new mirror. Having the signature on the package file update daily, even if the package file contents have not changed would be an easy way to detect a stale mirror. Just add a check on the signature time-stamp as part of checking the package signature, and warning if signature is too old. But the attack is not really applicable to Debian, where security updates come from trusted security mirrors, and not the general mirrors. If this were not the case, then the following statement from the site would be concerning: For example, it is known that an earlier version of OpenSSL for Debian has a security flaw. The list of files from the repository that previously included this package is still correctly signed. Using this old signed file list, a malicious mirror can keep a client on the insecure version of OpenSSL by responding to the client's package manager with the old list of files. As it is, the mirror can do no such thing. (Only a security mirror could do this) This is a very good thing. Indeed there is a second possible attack vector if the general mirrors were used for security updates. I could set my mirror up to watch for people requesting a specific security update. While the file is being downloaded, a script could automatically attempt to exploit the vulnerability on the system that requested the update. The idea is that there is a high probability that the system requesting the update has the insecure version installed, and is thus exploitable. However, if the security updates come from trusted security mirrors rather than a general mirror, that attack would fail too. So with the exception of Sid or Testing users that do not use the testing-security system to receive security updates, Debian really is not terribly vulnerable to this. But I still strongly recommend the signature time-stamp solution (which Don Armstrong suggested first) as it would let us notify users that a mirror is stale regardless of whether this is malicious, and it would help protect Sid and testing users. It would even add some additional security to Debian-derived distros that do not use a separate security mirror system. (Although they would still be vulnerable to the exploit while downloading issue.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
On Sat,12.Jul.08, 06:12:33, Joe Smith wrote: However, if the security updates come from trusted security mirrors rather than a general mirror, that attack would fail too. So with the exception of Sid or Testing users that do not use the testing-security system to receive security updates, Debian really is not terribly vulnerable to this. How about distributing the Release files *only* from a trusted server? Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Package management unsafe?
Andrei Popescu andreimpopescu at gmail.com writes: How about distributing the Release files *only* from a trusted server? Regards, Andrei That is problematic, as it does not deal with mirror synchronization properly. If a mirror takes a few hours to update, it's Packages files may not be up to date during those hours, resulting in apt claiming the Packages file is not validly signed. I see no benefits over re-signing the Release file daily, even if none of the Packages files (and hence the checksums and Release file itself) have changed, with apt then complaining if Release.gpg has a signature that is too old. This adds security against the published attack for testing users who do not use testing-security as well as sid users. It also helps warn users about non-malicious stale mirrors. As my post made clear, stable is already secure against the published attacked. The other attack I mentioned (the attack of attempting to exploit a flaw in any client that requests a security update) cannot be fixed in the general case, except by clients using a trusted server, or a trusted proxy that does not reveal the true requesting system's IP. Stable is safe because the security servers are trusted. Users of testing or sid should choose servers they trust or some form of trusted proxy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
Hello, On Sat, 2008-07-12 at 23:13 +, Joe Smith wrote: Andrei Popescu andreimpopescu at gmail.com writes: How about distributing the Release files *only* from a trusted server? The other attack I mentioned (the attack of attempting to exploit a flaw in any client that requests a security update) cannot be fixed in the general case, except by clients using a trusted server, or a trusted proxy that does not reveal the true requesting system's IP. Stable is safe because the security servers are trusted. Users of testing or sid should choose servers they trust or some form of trusted proxy. Stable is safe... as long as there's no man-in-the middle attack (e.g like a public wireless access-point with a transparent http proxy, if it's used over a long period of time). If we also consider the fact that the computer local time might be wrong (hwclock bug + a ntp man-in-the-middle...), re-signing the files doesn't help either [in this very specific case]. One costly solution would be to get the client the send a challenge to a trusted server, which would respond by gpg-signed the challenge + the checksum of current .Release file. Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
Joe Smith wrote: However, if the security updates come from trusted security mirrors rather than a general mirror, that attack would fail too. So with the exception of Sid or Testing users that do not use the testing-security system to receive security updates, Debian really is not terribly vulnerable to this. It would still be possible to mount this attack if the attacker can intercept packets on the way to the official trusted security mirror and redirect them (e.g. transparent proxy) to an older copy of the mirror. Brian May -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
On Sun, Jul 13, 2008 at 02:13:08AM +0200, Franklin PIAT wrote: If we also consider the fact that the computer local time might be wrong (hwclock bug + a ntp man-in-the-middle...), re-signing the files doesn't help either [in this very specific case]. I think that your average user would notice if the time were wrong. Even if the user isn't in an environment that is time-sensitive (e.g. a network using Kerberos), most people would wonder what happened if their computer's time were suddenly several days off. I think the much more likely case is that the time is accidentally incorrect, such as when a new machine is first installed. That may affect the installation of ntp itself, perhaps. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Package management unsafe?
On Fri, Jul 11, 2008 at 07:36:44AM -0500, Ron Johnson wrote: http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html What are people's thoughts on this? It's been known for quite a while. (I asked one of the guys publishing it, and he was fully aware of that, but felt it was still important to bring light to it.) In any case, it's pretty hard to exploit as long as you have security updates on a different (trusted) server. The best thing you can do is DoS the process so the user's package management software crashes, or simply never update your mirror so users don't get updates. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
Maybe a check should be added to APT to flag a warning if there has been no updates for a significant period of time? That way if a mirror ever does that, its more detectable. Michael On Fri, Jul 11, 2008 at 8:55 AM, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Fri, Jul 11, 2008 at 07:36:44AM -0500, Ron Johnson wrote: http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html What are people's thoughts on this? It's been known for quite a while. (I asked one of the guys publishing it, and he was fully aware of that, but felt it was still important to bring light to it.) In any case, it's pretty hard to exploit as long as you have security updates on a different (trusted) server. The best thing you can do is DoS the process so the user's package management software crashes, or simply never update your mirror so users don't get updates. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
* Ron Johnson: http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html What are people's thoughts on this? HTTPS doesn't help against non-trusted mirrors. The difficult question is how to tell an APT source which is not updated regularly from an APT source that has been rolled back in a replay attack. Apart from that, this is clearly a PR stunt. Next, we might see someone who tries to get into the project, with the intent to upload Trojanized packages--all in the name of academic research. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It doesn't have to have updated packages, maybe have something like this APT-Ping: *timestamp* and then push out a new packages file with just an updated timestamp in it. Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFId//JpblTBJ2i2psRAu6uAJ48+knPTzxi1InA/Wg3AN4m2Rt8WwCfa/ES rddl6+w/Kw+7UBVNQLjLplE= =fGdJ -END PGP SIGNATURE- On Fri, Jul 11, 2008 at 8:39 PM, Frank Lichtenheld [EMAIL PROTECTED] wrote: On Fri, Jul 11, 2008 at 11:48:03AM -0400, Michael Casadevall wrote: Maybe a check should be added to APT to flag a warning if there has been no updates for a significant period of time? That way if a mirror ever does that, its more detectable. That really doesn't make any sense for stable users since our point releases aren't exactly weekly ;) Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/
Re: Package management unsafe?
On Fri, Jul 11, 2008 at 11:48:03AM -0400, Michael Casadevall wrote: Maybe a check should be added to APT to flag a warning if there has been no updates for a significant period of time? That way if a mirror ever does that, its more detectable. That really doesn't make any sense for stable users since our point releases aren't exactly weekly ;) Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
On Sat, 12 Jul 2008, Frank Lichtenheld wrote: On Fri, Jul 11, 2008 at 11:48:03AM -0400, Michael Casadevall wrote: Maybe a check should be added to APT to flag a warning if there has been no updates for a significant period of time? That way if a mirror ever does that, its more detectable. That really doesn't make any sense for stable users since our point releases aren't exactly weekly ;) It wouldn't be a huge deal to re-sign the package list every n days and warn if the package list was signed more than n+r days ago. [This would even be useful to handle properly mirrors which are just out of date even without nefarious behavoir.] Don Armstrong -- Quite the contrary; they *love* collateral damage. If they can make you miserable enough, maybe you'll stop using email entirely. Once enough people do that, then there'll be no legitimate reason left for anyone to run an SMTP server, and the spam problem will be solved. -- Craig Dickson in [EMAIL PROTECTED] http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On management
On Mon, Mar 05, 2007 at 10:46:40PM +0100, Turbo Fredriksson wrote: Quoting Josselin Mouette [EMAIL PROTECTED]: I'm not convinced at all that *funding* a manager would do any good to the project. If we already had a _good_ project manager in our ranks, don't you think they/he/she would have stepped up already? Let's hope the existing managers have some pretty thick skin ;-) Regards, Paddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On management
Quoting [EMAIL PROTECTED]: On Mon, Mar 05, 2007 at 10:46:40PM +0100, Turbo Fredriksson wrote: Quoting Josselin Mouette [EMAIL PROTECTED]: I'm not convinced at all that *funding* a manager would do any good to the project. If we already had a _good_ project manager in our ranks, don't you think they/he/she would have stepped up already? Let's hope the existing managers have some pretty thick skin ;-) Sorry, I didn't mean it exactly how I wrote it. But there ARE a difference between a good manager and a _good_ one... Look elsewhere in the thread on examples... Our managers are techs. And a tech don't make a _good_ manager... -- pits nitrate counter-intelligence FBI arrangements Panama jihad Ft. Bragg subway cryptographic terrorist ammonium Albanian Treasury AK-47 [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. Note. This is a real, not fiction. http://www.theregister.co.uk/2001/09/06/eu_releases_echelon_spying_report/ http://www.aclu.org/safefree/nsaspying/23989res20060131.html#echelon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On management
Quoting cobaco (aka Bart Cornelis) [EMAIL PROTECTED]: So saying translators do it purely, or even mainly, for themselves is doing debian translators in general a disservice IMHO Dang, everyone is looking for stuff to criticize something today... But fine.. There ARE exeptions to any rule... And maybe I shouldn't have used the term 'themselves' so loosely, but the sentiment still applies... -- 767 ammunition PLO Rule Psix iodine Qaddafi CIA DES subway Kennedy Khaddafi AK-47 Ft. Bragg Noriega strategic [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. Note. This is a real, not fiction. http://www.theregister.co.uk/2001/09/06/eu_releases_echelon_spying_report/ http://www.aclu.org/safefree/nsaspying/23989res20060131.html#echelon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On management
Quoting Josselin Mouette [EMAIL PROTECTED]: I'm not convinced at all that *funding* a manager would do any good to the project. If we already had a _good_ project manager in our ranks, don't you think they/he/she would have stepped up already? THAT'S why I think paying for one might help... Which is why I'm wondering if there are ways to attract a few people with such profiles in the project. We have attracted many developers, sysadmins, translators, and everything we need to run the project; there must be a way to do the same for other profiles. Those are all technical (exept maybe translators, but they don't do it for the project, they do it for them selfs - which is a GOOD thing! It's easier to attract technical (hard?) skills than 'soft'... -- South Africa subway iodine Rule Psix CIA quiche supercomputer Uzi congress radar nitrate Semtex Soviet arrangements jihad [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. Note. This is a real, not fiction. http://www.theregister.co.uk/2001/09/06/eu_releases_echelon_spying_report/ http://www.aclu.org/safefree/nsaspying/23989res20060131.html#echelon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On management
On Monday 05 March 2007, Turbo Fredriksson wrote: (exept maybe translators, but they don't do it for the project, they do it for them selfs - which is a GOOD thing! The mere fact that you're able to translate kinda excludes you needing the translation in the first place (e.g. I translate cause I want to make Debian accessible to those whose english isn't good enough, and because I saw a niche to be filled there. On a purely personal level I prefer to run my software in English). There's also people like Clytie (vietnamese translator, very active) who don't even use Debian themselves. So saying translators do it purely, or even mainly, for themselves is doing debian translators in general a disservice IMHO -- Cheers, cobaco (aka Bart Cornelis) pgppUkgFuugFW.pgp Description: PGP signature
Re: On management
On Thu, 01 Mar 2007, Josselin Mouette wrote: That, I fully agree with. I also had the chance to see a good project manager in action, and that makes a huge difference. I'm not convinced at all that *funding* a manager would do any good to the project. Which is why I'm wondering if there are ways to attract a few people with such profiles in the project. We have attracted many developers, sysadmins, translators, and everything we need to run the project; there must be a way to do the same for other profiles. Do you believe that the DPL is not a management position ? In a recent discussion with Josip, we were talking about management vs leadership and he concluded that the DPL can't do much leadership because the real decisions are taken by all the teams/delegates, however his position is surely one of management since he needs to make sure that all teams interact correctly and they can rely on each other with confidence. There's some truth in that and I certainly expect a DPL team to have a big role to play in management and coordination. Contrary to Josip, I do think there's some leadership left, but only if he has enough time to invest in actually doing things instead of discussing with everybody. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On management
Hi, On Thursday 01 March 2007 22:28, Josselin Mouette wrote: First, please keep your bullshit about dunc-tank outside this otherwise interesting discussion. be liberal what you accept, and conservative what you send? regards, Holger pgpeWcMQwasHw.pgp Description: PGP signature
Re: On management
[Roberto C. Sanchez] I am not advocating having a manager without technical competency or the ability to understand technical issues. Just that being a manager does not require being a fourth-degree blackbelt in Perl or having written a textbook on C++ programming. And you think the current NM process is geared toward people who have a fourth-degree blackbelt in Perl or have written a textbook on C++ programming? My experience is that the expectations on new maintainers are far, far lower. You're supposed to know how to build packages that don't suck, but I don't remember noticing any test of my skills as a programmer, beyond simple shell scripting. If an applicant knows enough about Debian's technical side of things to be an effective manager for Debian processes, I don't see why that person should have any more trouble with NM than programmers do. Peter, also in NM signature.asc Description: Digital signature
Re: On management
On Fri, Mar 02, 2007 at 05:58:58PM -0600, Peter Samuelson wrote: [Roberto C. Sanchez] I am not advocating having a manager without technical competency or the ability to understand technical issues. Just that being a manager does not require being a fourth-degree blackbelt in Perl or having written a textbook on C++ programming. And you think the current NM process is geared toward people who have a fourth-degree blackbelt in Perl or have written a textbook on C++ programming? Not at all. It is biased in favor of those types of people. As a consequence of that, pretty much everyone with managerial responsibilities within the project is a very experienced DD and so has developed lots of those skills. I am not saying that this is a bad thing. Simply that many of those skills are not used as part of the managerial duties. Having technical understanding is still important as is knowing who the experts in various things are and when to trust their judgment and recommendations. My experience is that the expectations on new maintainers are far, far lower. You're supposed to know how to build packages that don't suck, but I don't remember noticing any test of my skills as a programmer, beyond simple shell scripting. I had to do some shell scripting as well to show that understood some of the things that dpkg and apt were doing behind the scenes. If an applicant knows enough about Debian's technical side of things to be an effective manager for Debian processes, I don't see why that person should have any more trouble with NM than programmers do. It's not that. What I was trying to get across was that there are people out there who are good mangers and have some technical knowledge and would be a great asset to the Debian project in a management capacity. However, that does not mean that such a person needs to pass the traditional NM process with all of its technical hurdles. Peter, also in NM Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: On management
Quoting Josselin Mouette [EMAIL PROTECTED]: As of now, I see it as a failure of the project. But this is also nothing that can't be fixed. What do you people think could be done to bring the skills we are lacking to the project, with its current structure? Since I agree (well, more than agree - I think it's absolutly vital :), how about actually PAYING them? Get one or two professionals and pay them (halftime perhaps)... I have no idea how the economy looks, but would there be room for such a thing? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On management
On Thu, Mar 01, 2007 at 03:28:50PM +0100, Turbo Fredriksson wrote: Quoting Josselin Mouette [EMAIL PROTECTED]: As of now, I see it as a failure of the project. But this is also nothing that can't be fixed. What do you people think could be done to bring the skills we are lacking to the project, with its current structure? Since I agree (well, more than agree - I think it's absolutly vital :), how about actually PAYING them? Get one or two professionals and pay them (halftime perhaps)... I have no idea how the economy looks, but would there be room for such a thing? A third party organization, dunc-tank, which included a number of prominent Debian Developers, including AJ, did pay for two of the release managers to work full-time for approximately a month at a time, at the end of 2006. This was actually highly contentious with some claiming that it delayed the release because it demotivated them. I know of now hard evidence to prove that the net result was negative, and certainly during the period when the two release managers were paid, the RC bug count did decline quite significantly, and you can see a significant difference in the slope and sign of the derivitive of the RC bug count before and after that period where two of the RM's were paid. Certainly the fact that we did pay them did cause a huge amount of flaming on various debian mailing lists, which perhaps might have delayed the release, but my personal opinion is that DD's being DD's, there would have found some other topic to flame about, whether it was license issues, or whether to expel a particular DD, or something else So I believe the paying RM's was a net positive, and there are those who would disagree with me. (And to be fair, I need to disclose that I was one of the people who helped to organize dunc-tank.) The harder problem, though is that finding a really good project manager. In my day job, I can tell you have as a technical architect, having a great project manager is like pure gold. My project manager defers to me on technical issues, but helps to coordinate all of the other technical teams so that we can make all of the schedules line up and release a coherent solution to the customer. Not to denigrate the efforts of the current release management team, but if we were to augment (NOT replace!) them with a good project manager, we could make them be far more effective. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On management
On 2007-03-01, Theodore Tso [EMAIL PROTECTED] wrote: A third party organization, dunc-tank, which included a number of prominent Debian Developers, including AJ, did pay for two of the How can it be a third party organization if it is launched by the DPL _as_ DPL ? (Source: AJs DPL review in his newest platform) /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On management
First, please keep your bullshit about dunc-tank outside this otherwise interesting discussion. Le jeudi 01 mars 2007 à 16:18 -0500, Theodore Tso a écrit : The harder problem, though is that finding a really good project manager. In my day job, I can tell you have as a technical architect, having a great project manager is like pure gold. My project manager defers to me on technical issues, but helps to coordinate all of the other technical teams so that we can make all of the schedules line up and release a coherent solution to the customer. Not to denigrate the efforts of the current release management team, but if we were to augment (NOT replace!) them with a good project manager, we could make them be far more effective. That, I fully agree with. I also had the chance to see a good project manager in action, and that makes a huge difference. I'm not convinced at all that *funding* a manager would do any good to the project. Which is why I'm wondering if there are ways to attract a few people with such profiles in the project. We have attracted many developers, sysadmins, translators, and everything we need to run the project; there must be a way to do the same for other profiles. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: On management
On Wed, Feb 28, 2007 at 02:58:12PM +0100, Josselin Mouette wrote: It should be obvious now that, with the delays the release is facing, this decision was wrong. I'm not so sure. By not trying to push 2.16 in, you've probably been creating a lot less work for the release team than if you were to push in 2.16 and then ask for hinting in new stuff through the freeze. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On management
On Wed, Feb 28, 2007 at 02:58:12PM +0100, Josselin Mouette wrote: Management is quite a different job that what most of us are doing. In the real world, a good manager is as rare a resource as a good engineer, and you need both to make a business running. The Debian project is currently good at attracting technically excellent people, but we also need a few people with management skills, and currently I fail to see what could bring them to work for the project. I would think that the same things that attract a technical individual could attract a non-technical individual. Desire to learn. Desire to contribute. Desire to build skills for resume or future employment. And so on. The thing is that the current NM process is heavily biased toward technical people/programmers/developers/etc. That is probably a discouragement to people who are more management oriented. Add to that the fact that the people in leadership and management roles in Debian now started out as developers and moved up. Someone with management might look and think I have the management skill, but I can't cut it in a technical role for three or four or whatever years to get that far in the project. I am not criticizing the current arrangement, I just think that if it is to become a goal to attract more skilled management-types, we need to create a sort of management track for new contributors. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: On management
Heya, I certainly agree with some of things you said, as I also believe that Debian could profit from better management and/or planning in some areas, I don't think this would have made the timely release of etch possible. Josselin Mouette [EMAIL PROTECTED] writes: Back in September, it seemed impossible to the GNOME team to bring GNOME 2.16 into a releasable state before the planned release date. We took then the hard decision to keep GNOME 2.14 and bring only the few parts of 2.16 that weren't disruptive (meaning especially, no gtk+ 2.10 and no gnome-vfs transition to dbus). It should be obvious now that, with the delays the release is facing, this decision was wrong. With the icon themes fixing, I think the last showstopper for GNOME 2.16 is now fixed. The point is that pushing Gnome 2.16 into the release would have taken even more time from the release team (and you and other maintainers), so that we would release at an even later point. And then the KDE team would come up and say that KDE 3.5.6 would be nice to have in etch. And XFCE 4.4 was also released recently, so we should probably have included it too. And by that point, etch would have been so late that Gnome 2.18 would be a candidate... Of course, at the time it became clear it would be possible to polish 2.16 before the release, the distribution was already frozen. The result is, we have a desktop with less bugs, more features and speed improvements, which is almost completely ready (apart from evince) for the upcoming stable release, and it's not going to be shipped. Currently it is only used by a handful of people running experimental. Right. The problem is that a large number of users would find a large number of bugs, which would show unexpected problems. Marc -- Fachbegriffe der Informatik - Einfach erklärt 173: Ada Ada ist der gelungene Versuch, die Schwächen von C, Pascal und Fortran in einer Sprache zu vereinigen. (Holger Spielmann) pgph7V8KLtYy0.pgp Description: PGP signature
Re: On management
I would think that the same things that attract a technical individual could attract a non-technical individual. Desire to learn. Desire to contribute. Desire to build skills for resume or future employment. And so on. The thing is that the current NM process is heavily biased toward technical people/programmers/developers/etc. That is probably a discouragement to people who are more management oriented. I'm not sure what you're advocating, but in my experience, project managers without the capacity to understand the technical issues of the project that they are supposed to be managing are worse than useless. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On management
On Wed, Feb 28, 2007 at 10:31:37AM -0500, Clint Adams wrote: I would think that the same things that attract a technical individual could attract a non-technical individual. Desire to learn. Desire to contribute. Desire to build skills for resume or future employment. And so on. The thing is that the current NM process is heavily biased toward technical people/programmers/developers/etc. That is probably a discouragement to people who are more management oriented. I'm not sure what you're advocating, but in my experience, project managers without the capacity to understand the technical issues of the project that they are supposed to be managing are worse than useless. I am not advocating having a manager without technical competency or the ability to understand technical issues. Just that being a manager does not require being a fourth-degree blackbelt in Perl or having written a textbook on C++ programming. The point is that there are people who understand the technical issues but are much more adept managers. All I am saying is that the current NM process (I am just at the tail end of it now) is heavily biased toward those with a strong interest in programming, system administration, and so on. I know that some people become DDs to work on documentation (a very important and thankless job), but they are by far the exception and not the rule. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: On management
On Wed, Feb 28, 2007 at 02:58:12PM +0100, Josselin Mouette wrote: [...] of people running experimental. As GNOME 2.18 is scheduled in two months, this means we will be lagging two versions behind upstream as soon as we have released. What's wrong with that? Many packages lag behind. The kernel, for instance, will also lag two versions behind upstream. OpenOffice.org will be version 2.0.x, while upstream has recently released 2.1. Heck, even my pet package nbd-server is lagging behind by a major version (2.8 vs 2.9). Yes, sometimes we have to make a choice which then eventually turns out to have been suboptimal. But the world won't end because we don't have the l33test version of GNOME in Debian; there's Ubuntu for that (and this is meant neither pejoratively nor negatively). Management is all about making choices based on available data and on risk assessments. Given the data that was available to the release team and the GNOME team at the time the decision was made, I do not think the choice to stick with GNOME 2.14 was wrong. It may turn out to have been suboptimal; but that doesn not mean it was the wrong decision at the time. As it turns out, getting GNOME 2.16 into etch would have been possible, so I agree that it's a pity it did not happen. However, we did not and could not know this back in September. Had we made the decision to go with 2.16 at the time, and had we ran into problems with doing that, then we might very well have been in the situation today that GNOME was currently delaying the release, rather than the kernel. I'm quite sure you prefer the current minor inconvenience over the alternative where people might have been bashing you all over the place for not getting your act together in time. Not only did it generate more work as we had two GNOME versions to maintain during the freeze, but it is now generating a lot of frustration because this extra work looks like a loss of time. The choice to get GNOME 2.16 into experimental was your own. While I could understand your frustration for lost time, it's hardly an argument for good (or bad) release management. It is my belief that such things could be avoided if we had proper release management. I'm quite utterly convinced that this is not true. I do agree that the release team made a bad call in deciding what would go into etch and what wouldn't. However, that bad call was related to GNOME -- it had everything to do with the kernel. GNOME was ready in time, but the kernel unfortunately isn't. Given that the release team made a single bad call in co-deciding which major subsystems could go in etch and which couldn't, I think they did a fairly good job. It's a pity they couldn't do better, but that doesn't mean they're not doing proper release management. [...] -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On management
argl On Wed, Feb 28, 2007 at 05:46:05PM +0100, Wouter Verhelst wrote: On Wed, Feb 28, 2007 at 02:58:12PM +0100, Josselin Mouette wrote: It is my belief that such things could be avoided if we had proper release management. I'm quite utterly convinced that this is not true. I do agree that the release team made a bad call in deciding what would go into etch and what wouldn't. However, that bad call was related to GNOME -- it had ^ -- not everything to do with the kernel. GNOME was ready in time, but the kernel unfortunately isn't. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On management
I'm not sure what you're advocating, but in my experience, project managers without the capacity to understand the technical issues of the project that they are supposed to be managing are worse than useless. But project manageers who understand too well the technical issues involved are also worse than useless because they tend to have an engineer point of voew on things rather than a manager point of view. The balance is pretty hard to find, indeed. We don't actually need people who can understand all the internals involved in the work of the GNOME team, or the kernel team, or D-i, or whatever. We probably more need people with enough abstraction and general view on the whole projectwho can then be able to driver things into the right direction and then make decisions at critical moments. That deeply involves taking the advice of the technically skilled members of the project, then take decisions from this. I think that I quite deeply agree with Joss on that issue. signature.asc Description: Digital signature
Re: Release management conclusions
* Matthew Wilcox ([EMAIL PROTECTED]) [060914 14:02]: On Wed, Sep 13, 2006 at 10:38:39AM +0300, Fabian Fagerholm wrote: However, the most recent publications indicate that volunteer incentive is not a well understood area of economics. In fact, it's one of the hot topics that economists are faced with when trying to explain the economics of FOSS: Seems to me if it's such a hot topic, we should be able to get a University to fund the experiment ;-) i have tried to find funding for other interested research (which i think would be even more interesting, but was not successfull. if you have contacts, please try! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tuesday 08 March 2005 10:46, David Härdeman [EMAIL PROTECTED] wrote: o Especially on laptops, it might be interesting to also encrypt all of /home and/or other parts of the harddrive to make the data unusuable without the USB key. But how to integrate this with the other requirements? It seems that this part of your message hasn't been addressed. The best thing to do regarding encryption (IMHO) is to have an encrypted root file system. Boot from a USB device and have an initrd use dm-crypt to decrypt the root file system. A password is not adequate on it's own (anything you can remember can be brute-forced). Get a key from /dev/random and maybe have a password as well. The root file system can contain keys for /home and other file systems. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Key management using a USB key
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Am Do den 17. Mär 2005 um 14:13 schriebst Du:
o Especially on laptops, it might be interesting to also encrypt all of
/home and/or other parts of the harddrive to make the data unusuable
without the USB key. But how to integrate this with the other
requirements?
I know of someone who set up a solution so the crypto partitions will
not be mounted if the smartcard is not plugged in.
I made such a solution using cfs for my own laptop. I do that by
mounting a encrypted dir and then setting $HOME to the new home.
Unfortunable not all applications take care for $HOME. Most important
gimp or pan and some other.
I only do crypthome newhome to use it. The directory can be generated
by:
gpg --gen-random 2 16 | gpg --symmetric key.gpg
gpg key.gpg | cmkdir -b -- newhome
mv key.gpg newhome/..p
Here how I did this (part of .bashrc):
cryptmount()
{
if [ X$1 == X ]; then
echo Please specify a directory!
return 1
fi
if [ -d /crypt/$1 ]; then
echo Directory still mounted!
return 0
fi
if _testcrypt $1 $1.gpg; then
CDIR=$1
CPWFILE=$1.gpg
elif _testcrypt .$1 .$1.gpg; then
CDIR=.$1
CPWFILE=.$1.gpg
elif _testcrypt $1 $1/..p; then
CDIR=$1
CPWFILE=$1/..p
elif _testcrypt .$1 .$1/..p; then
CDIR=.$1
CPWFILE=.$1/..p
elif _testcrypt $HOME/$1 $HOME/$1.gpg; then
CDIR=$HOME/$1
CPWFILE=$HOME/$1.gpg
elif _testcrypt $HOME/.$1 $HOME/.$1.gpg; then
CDIR=$HOME/.$1
CPWFILE=$HOME/.$1.gpg
elif _testcrypt $1; then
CDIR=$1
CPWFILE=
elif _testcrypt .$1; then
CDIR=.$1
CPWFILE=
elif _testcrypt $HOME/$1; then
CDIR=$HOME/$1
CPWFILE=
elif _testcrypt $HOME/.$1; then
CDIR=$HOME/.$1
CPWFILE=
else
echo File $1 not found!
return 1
fi
if [ X$CPWFILE == X ]; then
cattach $CDIR $1
else
gpg $CPWFILE | cattach -- $CDIR $1
fi
return $?
}
crypthome()
{
cryptmount $1 || return 1
sleep 1
until [ -d /crypt/$1 ]; do
sleep 1
done
cd /crypt/$1 herehome
echo Home directory chaged to /crypt/$1.
}
Regards
Klaus Ethgen
- --
Klaus Ethgenhttp://www.ethgen.de/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen [EMAIL PROTECTED]
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
iQEVAwUBQjmSvZ+OKpjRpO3lAQKZgAgAg4u6ybSUfCCPMHm00fYSzsn+rLwi+/wp
h4m+W+vwdpPczYlkTxIKkmzLHXMdv0qnsUa37kijU4KdaVOvxQbsCcWdI3Z5yw9Q
lheUU06Zm6YNCJlm30Vavb+hhCxK1jGLrIAwb5AxeE4dtdBAGifjzauF9ilwOooN
Tq7Wqh27kn+v8VTsWzsqoLCBSLnn4YSnGHtTVqhkCiFWt6kMgiqzVcBLBfXdktIl
xKjNTE9Zn534G3yKcrxXY4SuUmANt+fliSt7WPPfXDgt8u6YG5cCpJQTjjXivTaC
4pm7IvpMpcY6bSqgDr5gZzeJ8tHEA7FKJOQjLFVBMelJ4Yz1EEE4PQ==
=zhfn
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
Eric Dorland wrote: An arguably more secure approach would be to use a cryptographic smart card in a usb key form factor with OpenSC. Unfortunately integration with ssh and gpg is lacking at this point, but I hope to be able to do something about that post-sarge (ssh has support but doesn't compile it in, and gnupg support will come with gnupg 2.0). gnupg 1.4 (as in sid) supports OpenPGP cards like the one I'm presently using (bought from g10code). The form factor is Chipcard-Reader+Chipcard, but it's there. Kind regards Thomas -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
hi matthias, On Tue, Mar 15, 2005 at 08:02:34AM +0100, Matthias Urlichs wrote: - when gnupg releases an official version 2, james uploads a new gnupg that replaces the previous source package (or would it have to have the same name?), and generates all binary packages. That has been agreed to. i didn't see anything to that regard in the wnpp bug... do you have a pointer to somewhere that i could verify that? also, what about the library issue? assuming james is okay with it and there isn't some kind of library dependency issue, i'd gladly sponsor a gpg-agent. sean -- signature.asc Description: Digital signature
Re: Key management using a USB key
Hi,
sean finney:
That has been agreed to.
i didn't see anything to that regard in the wnpp bug... do you have
a pointer to somewhere that i could verify that?
I talked with elmo about it in Barcelona, last December.
He basically said that, as long as it's understood that he gets the
package back once gnupg2 is released, he has no problem with it.
FWIW, Ubuntu already has the package, in essentially the same form I've
been uploading it to Debian last week. Guess who Ubuntu's ftpmaster is...
also, what about the library issue?
Which library issue? AFAIK the packages co-exist nicely.
assuming james is okay with it and there isn't some kind of library
dependency issue, i'd gladly sponsor a gpg-agent.
Umm, s/sponsor/push it through NEW already, dammit/ ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: Key management using a USB key
hi, On Wed, Mar 16, 2005 at 01:39:44AM +0100, Matthias Urlichs wrote: also, what about the library issue? Which library issue? AFAIK the packages co-exist nicely. istr trying to build gpg-agent from the upstream source but the configure script would fail because i didn't have the appropriate version of one of the gpg-related libraries. the source package seems to build debs okay though, so at least i have something to play with... however, don't you think it's a little pre-emptive to have a gnupg2 binary package when they haven't yet released gnupg version 2? this smacks of the infamous redhat gcc release... assuming james is okay with it and there isn't some kind of library dependency issue, i'd gladly sponsor a gpg-agent. Umm, s/sponsor/push it through NEW already, dammit/ ;-) ah, sorry, can't help there. sean -- signature.asc Description: Digital signature
Re: Key management using a USB key
Hi, David Hrdeman wrote:
o gpg-agent support in the same manner as ssh-agent would be neat. I
understand that this requires gnupg 2.0 though.
While gpg-agent is built from the gnupg 2.0 sources (a development
snapshot of which is currently sitting in the NEW queue ...), the agent
itself is perfectly useable with gnupg 1.2.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Mon, Mar 14, 2005 at 09:30:54AM +0100, Matthias Urlichs wrote: o gpg-agent support in the same manner as ssh-agent would be neat. I understand that this requires gnupg 2.0 though. While gpg-agent is built from the gnupg 2.0 sources (a development snapshot of which is currently sitting in the NEW queue ...), the agent itself is perfectly useable with gnupg 1.2. then i'm wondering why someone hasn't packaged it already :) sean -- signature.asc Description: Digital signature
Re: Key management using a USB key
Hi,
sean finney:
On Mon, Mar 14, 2005 at 09:30:54AM +0100, Matthias Urlichs wrote:
o gpg-agent support in the same manner as ssh-agent would be neat. I
understand that this requires gnupg 2.0 though.
While gpg-agent is built from the gnupg 2.0 sources (a development
snapshot of which is currently sitting in the NEW queue ...), the agent
itself is perfectly useable with gnupg 1.2.
then i'm wondering why someone hasn't packaged it already :)
Because extracting it from gnupg2 source is *work*, and a package was
available for ages on my own server anyway.
Hopefully it'll be out of NEW sometime before Sarge...
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: Key management using a USB key
Hi Sean! sean finney [EMAIL PROTECTED]: On Mon, Mar 14, 2005 at 09:30:54AM +0100, Matthias Urlichs wrote: o gpg-agent support in the same manner as ssh-agent would be neat. I understand that this requires gnupg 2.0 though. While gpg-agent is built from the gnupg 2.0 sources (a development snapshot of which is currently sitting in the NEW queue ...), the agent itself is perfectly useable with gnupg 1.2. then i'm wondering why someone hasn't packaged it already :) Your fingers lie on a bloody wound. ;-) There was ITP #187548 for newpg, but was closed last summer. Please reopen it and make a package for newpg to make KMail-Users happy. see: Bug #280175 If you have not enough time, would you sponsor such package? Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 29. Oktober 2005 * Info: http://www.linux-info-tag.de * pgpzLYL0Ym2sL.pgp Description: PGP signature
Re: Key management using a USB key
* David Härdeman wrote: [...] o gpg-agent support in the same manner as ssh-agent would be neat. I understand that this requires gnupg 2.0 though. Should be no problem with quintuple-agent. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
hi, On Mon, Mar 14, 2005 at 02:19:46PM +0100, Erik Schanze wrote: Your fingers lie on a bloody wound. ;-) There was ITP #187548 for newpg, but was closed last summer. aha. Please reopen it and make a package for newpg to make KMail-Users happy. If you have not enough time, would you sponsor such package? i would be willing to do so only if james thought it was okay (it's his package, so it's his call). i think what would need to be done would be something along the lines of: - create a source package gnupg2 - gnupg2 *only* produces package(s?) for the peripheral binar(y|ies) - when gnupg releases an official version 2, james uploads a new gnupg that replaces the previous source package (or would it have to have the same name?), and generates all binary packages. james: thoughts? also, istr seeing something about gnupg2 needing a new version of some library already present in debian. if that's the case, i don't think this will fly at all. that said, there's nothing wrong with hosting binary packages somewhere else and if you do so without breaking my system i'll try them and build support for gpg-agent into the keyloader scripts. sean -- signature.asc Description: Digital signature
Re: Key management using a USB key
Hi, sean finney wrote:
- create a source package gnupg2
exists
- gnupg2 *only* produces package(s?) for the peripheral binar(y|ies)
a binary for gnupg2 exists too, with a warning that it's not for public
consumption
- when gnupg releases an official version 2, james uploads a new gnupg
that replaces the previous source package (or would it have to have
the same name?), and generates all binary packages.
That has been agreed to.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Wednesday 09 March 2005 01:42, David Härdeman wrote: So the revocation could even be stored in cleartext on the usb key, unless I'm mistaken? Depending on the strength of the crypto/passphrase protecting your key, this could lead at least to a DOS if the revocation is publicised without compromising your keys. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Key management using a USB key
On Tue, 8 Mar 2005, sean finney wrote: you could easily extend the script i wrote to unencrypt/loop-mount a filesystem-in-a-file without too much effort. prod me enough and i might do it myself. Prodding. :) Moreover I'd suggest to send the result of it as patch to the gpg package for inclusion into /usr/share/doc/gpg/examples . Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
* David Pashley | Ideally I want to keep the disk formatted as vfat so it is usable on | other operating systems and use an ext2 loopback filesystem. Getting the | system to mount that is the hard part. You could partition the usb key and have a small partition for GPG/SSH keys and the rest for normal data transfers and stuff. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Wed, 2005-03-09 at 11:34 +0100, Tollef Fog Heen wrote: You could partition the usb key and have a small partition for GPG/SSH keys and the rest for normal data transfers and stuff. I was going to do the same, but picked up a rediculously cheap tiny USB key, and only use it for this purpose. Then I protect it with my life... I have a larger vfat key that I use for transfers etc too.. -- [EMAIL PROTECTED] - www.seigan.org PGP Key fingerprint = 4309 1C58 5143 AFAC F69E 11CD 76FD 56D4 1223 E387 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 12:46:46AM +0100, David Härdeman wrote: I've been meaning for some time to get a USB key to manage private keys (such as gpg, ssh, etc), but it's not until recently that I tried to sit down and sketch on how to implement it (filesystem layout, functionality, which parts are encrypted and accessed at which points in time etc). It turns out that it was not as obious as I thought. [...] It would be very interesting to hear how others manage this... Ok, based on the script from Sean Finney and the feedback from the others (thanks all!). I've written a rough draft of how *I* would like things to work. It's divided into three parts, and also requires the keychain tool[1]. The first file, is a simple udev rule which creates a /dev/cryptdisk node when the appropriate usb key is inserted (proper as decided by the various conditions which one can list in a udev rule). It can be placed in /etc/udev/rules.d/cryptkey.rules. Then, a script which is run after the appropriate device node is created or removed. This script is plopped into /etc/dev.d/block/cryptdisk.dev. This script mounts the drive, checks who it belongs to (by reading the keyowner file in the root dir of the USB key), mounts it again with the proper permissions for that user and then calls the third piece. The third script, which is run as the user who owns the key, loads the ssh keys from the usb key and into ssh-agent. The advantage is that this script can also be called from eg. .xsession to load keys from usb devices which were already present during boot. It also allows one to load keys even if X isn't running. The scripts are a bit rough at the moment, I wrote them in a hurry, but I'll clean them up a bit more later, I wanted to get something through the door. They work-for-me right now (loading keys, with ssh-askpass dialogue, and removing them when the usb key is removed). I'll work more on the scripts during the weekend (adding some of the TODO's, documentation). Regards, David [1] http://www.gentoo.org/proj/en/keychain/index.xml [2] http://www.hardeman.nu/~david/keyload/ PS Right now, the scripts are licensed under a david-owes-sean-a-pizza license =) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On 07-Mar-05, 17:46 (CST), David H?rdeman [EMAIL PROTECTED] wrote: o Revocation certificates for the gpg keys, are there arguments for/against storing them on the usb key? While you might store the revocation certificate (RC) on *a* key, I certainly wouldn't store it on *the* key. If you lose the usb key with the gpg keys, you do want to be able to revoke them, right? Since the RCs are not something I need regularly, I put mine on a couple of CDs, and printed a copy (worst case). Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, 2005-03-08 at 00:46 +0100, David Härdeman wrote: first of all, this might be slightly off-topic for the debian-devel list, but I've got the impression that it's already been solved by some DD's and might prove interesting to others (including non-DD's such as me). I use a very small USB key for my gnupg and ssh keys. I had created the .gnupg and .ssh directories in my home a long time ago, so I formatted the USB device as ext2, and copied the two directories to the USB device as ssh and gnupg. In my home directory I create a symlink for /media/usbkey/ssh - ~/.ssh and /media/usbkey/gnupg - ~/.gnupg. So, when I stick the dongle into the USB slot, the drive is automatically mounted, and the symlinks point to my real key directories. When the key is out of the machine, my keys are safe offline. HTH Ben
Re: Key management using a USB key
On Tue, 2005-03-08 at 14:58 +, Ben Hill wrote: In my home directory I create a symlink for /media/usbkey/ssh - ~/.ssh and /media/usbkey/gnupg - ~/.gnupg. It has to be said, this method isn't the most secure method by any means, and I'm interested to hear other's approaches. Cheers, Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
Op di, 08-03-2005 te 14:58 +, schreef Ben Hill: On Tue, 2005-03-08 at 00:46 +0100, David Hrdeman wrote: first of all, this might be slightly off-topic for the debian-devel list, but I've got the impression that it's already been solved by some DD's and might prove interesting to others (including non-DD's such as me). I use a very small USB key for my gnupg and ssh keys. I had created the .gnupg and .ssh directories in my home a long time ago, so I formatted the USB device as ext2, and copied the two directories to the USB device as ssh and gnupg. In my home directory I create a symlink for /media/usbkey/ssh - ~/.ssh and /media/usbkey/gnupg - ~/.gnupg. So, when I stick the dongle into the USB slot, the drive is automatically mounted, and the symlinks point to my real key directories. When the key is out of the machine, my keys are safe offline. This is also approximately how I manage this (or did, my key broke yesterday and I haven't got a new one yet). The only difference is that, rather than symlinking ~/.gnupg, I symlink ~/.gnupg/secring.gpg; that way, I can mount the USB key read-only, which allows me to safely remove it while still mounted; my trustdb and public keyring are synchronized in other ways. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 02:58:41PM +, Ben Hill wrote: In my home directory I create a symlink for /media/usbkey/ssh - ~/.ssh and /media/usbkey/gnupg - ~/.gnupg. One can also use the --home flag to gpg. -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 It's sex! Sex is the game! Marriage is the penalty. --Andrew Wyke (Sleuth) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 04:07:02PM +0100, Wouter Verhelst wrote: The only difference is that, rather than symlinking ~/.gnupg, I symlink ~/.gnupg/secring.gpg; that way, I can mount the USB key read-only, which allows me to safely remove it while still mounted; my trustdb and public keyring are synchronized in other ways. Lovely idea. No need for rebuilding the trust path in the USB key. -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 I'm a mog: half man, half dog. I'm my own best friend! --Barf (Spaceballs) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, 2005-03-08 at 16:07 +0100, Wouter Verhelst wrote: The only difference is that, rather than symlinking ~/.gnupg, I symlink ~/.gnupg/secring.gpg; that way, I can mount the USB key read-only, which allows me to safely remove it while still mounted; my trustdb and public keyring are synchronized in other ways. That's a nice idea. I might use that for the .ssh too, leaving known_hosts to be synchronized using another method. -- [EMAIL PROTECTED] - www.seigan.org PGP Key fingerprint = 4309 1C58 5143 AFAC F69E 11CD 76FD 56D4 1223 E387 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
Wouter wrote: Op di, 08-03-2005 te 14:58 +, schreef Ben Hill: So, when I stick the dongle into the USB slot, the drive is automatically mounted, and the symlinks point to my real key directories. When the key is out of the machine, my keys are safe offline. This is also approximately how I manage this (or did, my key broke yesterday and I haven't got a new one yet). The only difference is that, rather than symlinking ~/.gnupg, I symlink ~/.gnupg/secring.gpg; that way, I can mount the USB key read-only, which allows me to safely remove it while still mounted; my trustdb and public keyring are synchronized in other ways. Yep, exactly how I do it too. It works well - after all, you rarely (if ever) need to update the contents then. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop -- Vivek Dasmohapatra -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Mar 08, 2005 at 14:58, Ben Hill praised the llamas by saying: On Tue, 2005-03-08 at 00:46 +0100, David Härdeman wrote: first of all, this might be slightly off-topic for the debian-devel list, but I've got the impression that it's already been solved by some DD's and might prove interesting to others (including non-DD's such as me). I use a very small USB key for my gnupg and ssh keys. I had created the .gnupg and .ssh directories in my home a long time ago, so I formatted the USB device as ext2, and copied the two directories to the USB device as ssh and gnupg. Ideally I want to keep the disk formatted as vfat so it is usable on other operating systems and use an ext2 loopback filesystem. Getting the system to mount that is the hard part. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, 2005-03-08 at 15:41 +, David Pashley wrote: Ideally I want to keep the disk formatted as vfat so it is usable on other operating systems and use an ext2 loopback filesystem. Getting the system to mount that is the hard part. I initially had my stuff stored on a VFAT partition, and that caused issues with file locks. I do have my entire ~/.ssh and ~/.gnupg on there, but if it were a read only link to the private key, that probably isn't an issue. -- [EMAIL PROTECTED] - www.seigan.org PGP Key fingerprint = 4309 1C58 5143 AFAC F69E 11CD 76FD 56D4 1223 E387 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 02:30:06AM -0500, sean finney wrote: well, me wanting to do things the right way it ended up being a pretty long script and i didn't think the list would appreciate random shell scripts flying around. but, i'll go ahead and put it online: http://www.seanius.net/linux/keyloader/usb-storage Thanks Sean and everyone else for contributing. Based on the above script and the suggestions from everyone else, I've got a basic idea of how I'd want this to work: o usb key contains a vfat filesystem with two special files, one names the user for the keychain, while the other is a storage file to be used as a loopback drive. o use the keychain script sean mentioned to keep one ssh-agent running per user no matter how many sessions (which has other advantages than those relating to usb key management). o when the usb key is inserted, the user is prompted for a password to the encrypted loopback file which is then mounted, the ssh keys within are fed to ssh agent, and the file is unmounted again. Pros: o the ssh key only exists in the memory of the ssh agent (except for a short time period when the loopback file is mounted) o hopefully, in combination with libpam-usb and/or libpam-mount, it would be possible to reduce the number of password prompts to one. o vfat filesystem means that the key is usable on most OS:es (as a normal data carrier) and that it can be easilly backed up and recreated. Meanwhile the loopback file allows for the features one expect in a unixy system such as proper permissions etc. Cons: o Only I've come up with so far is that there will be some dependencies which might not be available on any host computer. And that the keys wont be usable at all should one need to use them on a windows computer (if they are locked into a ext2-loopback file that is). Bonus stuff: o It would be a neat trick to have the keys which were once loaded from the usb key into the ssh agent automatically removed from the agent when the key is removed from the computer (meaning you could quickly yank the key, go for lunch, return, reinsert it and continue working). o gpg-agent support in the same manner as ssh-agent would be neat. I understand that this requires gnupg 2.0 though. o check both at insertion time and at first login time for the usb key (so that the key can be either inserted from boot or inserted during an existing session). I'll probably keep the main vfat partition mounted for access to general data stored on the key while it is inserted, a neat trick would then be to automatically remove the keys from the ssh agent which were once upon a time loaded I have started working on some scripts to do the above. Currently, they consist of three parts: o a udev rule file which gives a special device node to the usb key o a /dev/udev.d file which is run after the node is created that does the necessary root-level setup and then calls o a user-specific script which loads the keys (and prompts for necessary passwords) etc. I think this setup should allow all the bonus stuff to be implemented as well. The only real problem I've found so far is bug 290324 (http://bugs.debian.org/290324) which makes it hard to have user-mounted-dm-crypt-over-loopback-device goodness, and the patch attached to that bug seems to have bitrotted a bit. I'll get back to you when I have something real to show. Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 07:29:20AM -0600, Steve Greenland wrote: On 07-Mar-05, 17:46 (CST), David H?rdeman [EMAIL PROTECTED] wrote: o Revocation certificates for the gpg keys, are there arguments for/against storing them on the usb key? While you might store the revocation certificate (RC) on *a* key, I certainly wouldn't store it on *the* key. If you lose the usb key with the gpg keys, you do want to be able to revoke them, right? Since the RCs are not something I need regularly, I put mine on a couple of CDs, and printed a copy (worst case). Sorry, I was being vague. I did of course intend to have the revocation certificates on the key in *addition* to alternative forms of storage. My concern was rather if there was any problems with this. As far as I can understand, all that a malicous persom who found the key could do with the revocation cert would be to revoke my gpg key right?...which would not be a problem as I would have to assume the worst and perform the revocation anyway should the usb key be lost. So the revocation could even be stored in cleartext on the usb key, unless I'm mistaken? Re, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
hello, On Wed, Mar 09, 2005 at 01:38:22AM +0100, David Härdeman wrote: o when the usb key is inserted, the user is prompted for a password to the encrypted loopback file which is then mounted, the ssh keys within are fed to ssh agent, and the file is unmounted again. you could easily extend the script i wrote to unencrypt/loop-mount a filesystem-in-a-file without too much effort. prod me enough and i might do it myself. o hopefully, in combination with libpam-usb and/or libpam-mount, it would be possible to reduce the number of password prompts to one. you should only need a password for encrypted things. since the hotplug script runs as root you can have that take care of all the other details. so, as long as you have either an unencrypted ext2 filesystem-file with encrypted ssh-keys or vice versa, you should only need one password. Bonus stuff: o It would be a neat trick to have the keys which were once loaded from the usb key into the ssh agent automatically removed from the agent when the key is removed from the computer (meaning you could quickly yank the key, go for lunch, return, reinsert it and continue working). my script already does this. in fact, it's selective enough to leave other keys that it didn't load still in memory. this was a little tricky to accomplish, and is done by copying the public key into a temporary location (under /var/cache/keyloader/pubkeys/$USER), and when the device is removed those keys are passed to ssh-add -d. o check both at insertion time and at first login time for the usb key (so that the key can be either inserted from boot or inserted during an existing session). that would be nice, though a quick workaround is to remove and re-insert the key :). o a /dev/udev.d file which is run after the node is created that does the necessary root-level setup and then calls o a user-specific script which loads the keys (and prompts for necessary passwords) etc. better watch out where root and the user cross paths... sean -- signature.asc Description: Digital signature
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 12:46:46AM +0100, David Härdeman wrote: o In order to minimize the exposure of the key, it might be wise to mount the drive, load the keys (ssh,gpg) into the memory of the appropriate agents and then unmount the drive. On the other hand, does this actually provide any extra security as opposed to having the key mounted for the entire session? i have a usb/hotplug/ssh-add script that loads an ssh key off of a usb stick, and removes it when the usb stick is removed. if you're interested i can send you a copy off-list. sean -- signature.asc Description: Digital signature
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 12:46:59AM -0500, sean finney wrote: On Tue, Mar 08, 2005 at 12:46:46AM +0100, David Härdeman wrote: o In order to minimize the exposure of the key, it might be wise to mount the drive, load the keys (ssh,gpg) into the memory of the appropriate agents and then unmount the drive. On the other hand, does this actually provide any extra security as opposed to having the key mounted for the entire session? i have a usb/hotplug/ssh-add script that loads an ssh key off of a usb stick, and removes it when the usb stick is removed. if you're interested i can send you a copy off-list. Any reason not to post it on-list? I was hoping to improve the security/usability of my own setup based on the best practices offered up in reply to this thread. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Key management using a USB key
An arguably more secure approach would be to use a cryptographic smart card in a usb key form factor with OpenSC. Unfortunately integration with ssh and gpg is lacking at this point, but I hope to be able to do something about that post-sarge (ssh has support but doesn't compile it in, and gnupg support will come with gnupg 2.0). * David H?rdeman ([EMAIL PROTECTED]) wrote: Hi all, first of all, this might be slightly off-topic for the debian-devel list, but I've got the impression that it's already been solved by some DD's and might prove interesting to others (including non-DD's such as me). I've been meaning for some time to get a USB key to manage private keys (such as gpg, ssh, etc), but it's not until recently that I tried to sit down and sketch on how to implement it (filesystem layout, functionality, which parts are encrypted and accessed at which points in time etc). It turns out that it was not as obious as I thought. Things which I've considered so far: o In order to minimize the exposure of the key, it might be wise to mount the drive, load the keys (ssh,gpg) into the memory of the appropriate agents and then unmount the drive. On the other hand, does this actually provide any extra security as opposed to having the key mounted for the entire session? o Password entry, it's a hassle to enter 10 different passwords, what would be the best way to reduce the number of password entries? dm-crypt to mount an encrypted file on the USB key and then have the gpg and ssh keys unencrypted within? The login to X/console etc could then maybe be performed using libpam-usb [1] so that only the password for the dm-crypt filesystem is needed? o Especially on laptops, it might be interesting to also encrypt all of /home and/or other parts of the harddrive to make the data unusuable without the USB key. But how to integrate this with the other requirements? o Revocation certificates for the gpg keys, are there arguments for/against storing them on the usb key? o Automagic setup. Hopefully, some scripts in conjunction with udev/hotplug/pmount/whatever could make everything just work (tm) when the key is inserted. o USB key removal, how should it be handled if the key is physically removed during a session? Maybe kill the agents and run xscreensaver until the key is reinserted... o Permissions, how are these handled when the key moves between systems where my userid might differ? o Other issues? It would be very interesting to hear how others manage this... Kind regards, David [1] http://bugs.debian.org/234134 -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Key management using a USB key
On Mon, 7 Mar 2005 21:52:31 -0800, Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Mar 08, 2005 at 12:46:59AM -0500, sean finney wrote: On Tue, Mar 08, 2005 at 12:46:46AM +0100, David Härdeman wrote: o In order to minimize the exposure of the key, it might be wise to mount the drive, load the keys (ssh,gpg) into the memory of the appropriate agents and then unmount the drive. On the other hand, does this actually provide any extra security as opposed to having the key mounted for the entire session? i have a usb/hotplug/ssh-add script that loads an ssh key off of a usb stick, and removes it when the usb stick is removed. if you're interested i can send you a copy off-list. Any reason not to post it on-list? I was hoping to improve the security/usability of my own setup based on the best practices offered up in reply to this thread. I would suggest putting the script in the Debian wiki. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Key management using a USB key
Any reason not to post it on-list? I was hoping to improve the security/usability of my own setup based on the best practices offered up in reply to this thread. Yep. Seconded. This is exactly what I was thinking while seeing this thread : let's watch it and learn how my fellow DD and Debian contributors handle this and improve the (certainly very bad) way I have to handle this myself. A few months ago, I got my hands on a few USB encryption keys (or whatever these things are callediKey stuff for instance) and imagined I could store sensitive data there. I look vaguely at things which are supposed to handle these in Linux (PC/SC stuff and such things)...but, well, this was quite obscure and I finally gave up. But I still have a few of these keys...:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
hi, On Mon, Mar 07, 2005 at 09:52:31PM -0800, Steve Langasek wrote: i have a usb/hotplug/ssh-add script that loads an ssh key off of a usb stick, and removes it when the usb stick is removed. if you're interested i can send you a copy off-list. Any reason not to post it on-list? I was hoping to improve the security/usability of my own setup based on the best practices offered up in reply to this thread. well, me wanting to do things the right way it ended up being a pretty long script and i didn't think the list would appreciate random shell scripts flying around. but, i'll go ahead and put it online: http://www.seanius.net/linux/keyloader/usb-storage how it works: - plop the script in /etc/hotplug/usb/ - copy your public/private keys onto a usb disk, list them in ~/.keyloader (KEYS=key1 key2, read script comments for more info) - plug in the usb disk - ssh-add xterm (or ssh-askpass if you have it installed) pops up if it needs a passphrase, and your key is loaded - remove the disk - key is unloaded. i think the approach i take is fairly sound securitywise, but i'd appreciate someone else taking a look at it. also, i'm not sure whether it still works on 2.4 kernels, i haven't had a 2.4 machine to test on in a while. sean -- signature.asc Description: Digital signature
Re: dm management of wm listings (kdm/gdm/etc..)
Ivan Solution?: create a program (update-dm?) that would pull Ivan the current list of window/session-managers installed on the Ivan system and build the appropriate config files for whichever You should probably consider whether this program ought to simply be update-menu. Is there any reason not to have a menu of window managers? You could then have the method for the DM only pull window managers. Note this is a serious question; there may well be many good reasons this is a bad idea. hmmm...well menu already has the wm bit and if wm's create a menu entry using this that would allow for singling them out. menu also has the ability to do just about anything theoretically and would require no other programs except for customized menu-methods for each dm provided by the dm's. I don't see a reason why it can't be used. It's a *MUCH* cleaner approach than using the alternatives list and allows for proper names (ie.. Gnome vs. gnome-session). /me runs off to try it with kdm... Ivan -- Ivan E. Moore II [EMAIL PROTECTED] http://snowcrash.tdyc.com GPG KeyID=90BCE0DD GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
Re: dm management of wm listings (kdm/gdm/etc..)
On Thu, May 03, 2001 at 03:11:19AM -0600, Ivan E. Moore II wrote: Hi, Branden and I discussed the issue of dm's that have wm lists to choose from several months ago. At that time he thought that maybe the update-menu type of approach would be a good way to solve this. I'd like to restate what my understanding of the problem and current suggested solution and see what people think. (and then find out where we go next from here) Problem: Desktop Managers like kdm and gdm support Window Manager listings so that users can choose what they want to login in using. There currently is no common way for wm's to register themselves with each/any/all dm's that may be installed on the system. mmm, here you are talking the graphical login prompt (don't know it's propper name) who ask for what kind of session you are wanting. As an example, gdm currently proposes to launch gnome-session, whatever is in Xsession or xsm. Note that these are no window managers? For the gnome session, you can then choose the window-manager in the control center. Is it this you are speaking about ? Friendly, sven Luther
Re: dm management of wm listings (kdm/gdm/etc..)
On Thu, 3 May 2001, Ivan E. Moore II wrote: Problem: Desktop Managers like kdm and gdm support Window Manager listings so that users can choose what they want to login in using. There currently is no common way for wm's to register themselves with each/any/all dm's that may be installed on the system. Solution?: create a program (update-dm?) that would pull the current list Why not use the Menu System. There are already items for changing the current window manager like ?package(icewm):command=/usr/bin/X11/icewm icon=none needs=wm \ section=WindowManagers title=IceWM which most of the small and nice Window-Managers implement cleanly. (At least in potato) Why not us this info? Hochachtungsvoll, Bernhard R. Link (I already thought of changing wdm to use this, when I'm done with the strange radius/nis-combination I have to cope with actually).
Re: dm management of wm listings (kdm/gdm/etc..)
Ivan E. Moore II schrieb:
I think that this method would probably reduce the amount of possible
duplication as long as the update-dm script pulled it's wm listing from
/var/lib/dpkg/alternatives/x-window-manager for example. That way the only
change any wm would have to do is add a call to update-dm in it's postinst.
All dm's that would use this feature would then create a custom file and
install it into /etc/X11/dm (for example) and run update-dm in it's postinst
as well.
Have a look at update_wdm_wmlist, it get's a list of WMs by
looking at the x-{window,session}-manager alternatives.
Using the menu system's needs=wm entries would probably yield
too long titles for WDM.
ciao, 2ri
--
Never is almost always earlier than you think.
Re: dm management of wm listings (kdm/gdm/etc..)
Sven LUTHER wrote: On Thu, May 03, 2001 at 03:11:19AM -0600, Ivan E. Moore II wrote: Hi, Branden and I discussed the issue of dm's that have wm lists to choose from several months ago. At that time he thought that maybe the update-menu type of approach would be a good way to solve this. I'd like to restate what my understanding of the problem and current suggested solution and see what people think. (and then find out where we go next from here) Problem: Desktop Managers like kdm and gdm support Window Manager listing so that users can choose what they want to login in using. There currently is no common way for wm's to register themselves with each/any/all dm's that may be installed on the system. mmm, here you are talking the graphical login prompt (don't know it's propper name) Display Manager (dm) who ask for what kind of session you are wanting. As an example, gdm currently proposes to launch gnome-session, whatever is in Xsession or xsm. Note that these are no window managers? For the gnome session, you can then choose the window-manager in the control center. gnome-session, startkde and whatnot _are_ window managers as far as the dm is concerned. AFAICT Ivan's approach is good if menu can't be (ab)used for this purpose. -- Earthling Michel Dänzer (MrCooper)\ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \XFree86 and DRI project member
Re: dm management of wm listings (kdm/gdm/etc..)
Ivan == Ivan E Moore [EMAIL PROTECTED] writes: Ivan Solution?: create a program (update-dm?) that would pull Ivan the current list of window/session-managers installed on the Ivan system and build the appropriate config files for whichever You should probably consider whether this program ought to simply be update-menu. Is there any reason not to have a menu of window managers? You could then have the method for the DM only pull window managers. Note this is a serious question; there may well be many good reasons this is a bad idea.
Re: dm management of wm listings (kdm/gdm/etc..)
On Thu, May 03, 2001 at 03:11:19AM -0600, Ivan E. Moore II wrote: Problem: Desktop Managers like kdm and gdm support Window Manager listings so that users can choose what they want to login in using. There currently is no common way for wm's to register themselves with each/any/all dm's that may be installed on the system. Since every window manager / session manager is already registered with the alternatives system, I see no reason why the other display managers can't do what wdm already does. It includes a script, update_wdm_wmlist which essentially just greps the output of 'update-alternatives --display x-window-manager' and 'update-alternatives --display x-session-manager' and populates its menu based on that. Since all window managers and desktop environments are already registered with the alternatives system, I don't see any reason to complicate things any further. noah -- wdm maintainer -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpvheyvVZYGx.pgp Description: PGP signature
Re: dm management of wm listings (kdm/gdm/etc..)
Noah L. Meyerhans wrote: On Thu, May 03, 2001 at 03:11:19AM -0600, Ivan E. Moore II wrote: Problem: Desktop Managers like kdm and gdm support Window Manager listings so that users can choose what they want to login in using. There currently is no common way for wm's to register themselves with each/any/all dm's that may be installed on the system. Since every window manager / session manager is already registered with the alternatives system, I see no reason why the other display managers can't do what wdm already does. It includes a script, update_wdm_wmlist which essentially just greps the output of 'update-alternatives --display x-window-manager' and 'update-alternatives --display x-session-manager' and populates its menu based on that. Does this handle window managers which are installed after wdm, and if yes how? -- Earthling Michel Dänzer (MrCooper)\ Debian GNU/Linux (powerpc) developer CS student, Free Software enthusiast \XFree86 and DRI project member
Re: dm management of wm listings (kdm/gdm/etc..)
On Thu, May 03, 2001 at 05:20:55PM +0200, Michel Dänzer wrote: Since every window manager / session manager is already registered with the alternatives system, I see no reason why the other display managers can't do what wdm already does. It includes a script, update_wdm_wmlist which essentially just greps the output of 'update-alternatives --display x-window-manager' and 'update-alternatives --display x-session-manager' and populates its menu based on that. Does this handle window managers which are installed after wdm, and if yes how? It does. /etc/init.d/wdm checks for 'auto-update-wmlist' in /etc/X11/wdm/wdm.options. If found, it runs the script to update the menu entry (found in /etc/X11/wdm/wdm-config). It does the same thing in /etc/X11/wdm/Xreset, so when an X session ends, the menu is updated with any changes before wdm comes up again. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpWLojNWHkde.pgp Description: PGP signature
Re: Release management - technical
Enrique Zanardi wrote: On Mon, Jun 22, 1998 at 01:38:21PM +0100, Ian Jackson wrote: Enrique Zanardi writes (Re: Release management - technical): On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote: ... I think we can only do one of these. With hamm we're doing the latter; in the future I think we should do the former. Fine, as long as we have some long term goals that must be achieved, better sooner than later (FHS compliance, for example). NO! Absolutely not, if you're going to say `must be achieved'. I read `must be achieved' to mean `we will delay the release if these are not achieved'. Oops. That's not what I wanted to express. Long-term goals shouldn't delay the release. Personally I have the feeling that it should read must be achieved but that long-term-goals should be broken up in realisable chunks. Otherwise there is never a deadline for things and even if you can't coerce somebody to do something, a dealine still forces some preassure on people. (This is incidently the reason why the freeze caused so many uploads and made the distribution unstable for a while). In the libc5 to libc6 changeover we had get the fundamental libs going and then get the apps those landmarks could have made a realease possible. The problem, IMHO is that we were to ambitious not that it is inherently wrong to strive for some release goals. I agree. An example of long term goal is apt. We want to substitute dselect with apt eventually, and there is a group of volunteers working towards it, but that goal won't delay hamm's release.. But getting the command-line backend working is one of the subgoals and having it has produced a release landmark. Luis. -- Luis Francisco Gonzalez [EMAIL PROTECTED] PGP Fingerprint = F8 B1 13 DE 22 22 94 A1 14 BE 95 8E 49 39 78 76 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release management - technical
Enrique Zanardi writes (Re: Release management - technical): On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote: ... I think we can only do one of these. With hamm we're doing the latter; in the future I think we should do the former. Fine, as long as we have some long term goals that must be achieved, better sooner than later (FHS compliance, for example). NO! Absolutely not, if you're going to say `must be achieved'. I read `must be achieved' to mean `we will delay the release if these are not achieved'. We are a volunteer organisation, and the last 13 months have shown us that you can't guilt people into doing things. We should continue to have `long term goals', and I applaud people who work towards them, but we must be able to make a release even when they are not met. It is better to have a release now and goals later than no release now and goals later ! David Engel writes (Re: Release management - technical): On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote: Q. What are we trying to achieve ? A. There are two possibilities that I can see - Timely and good-quality releases, or - Releases which meet some predefined set of goals. I think we can only do one of these. With hamm we're doing the latter; in the future I think we should do the former. I disagree. Timely and good-quality releases is just another goal. What we haven't done been able to do in the past is strike a balance and have sacrificed timely releases in favor of other goals. I don't see how timely and good-quality releases work against our other goals, per se. What has been happening so far is that we've been saying `Ner! We _shan't_ have a timely release unless we meet these goals, so you _must_ go and work on the goals.' This has FAILED. In future, we should make releases _without regard to long term goals_. Since we have to be incrementally-upgradeable, long term goals can be achieved just as easily out of step with releases. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release management - technical
On Mon, 22 Jun 1998, Ian Jackson wrote: We should continue to have `long term goals', and I applaud people who work towards them, but we must be able to make a release even when they are not met. It is better to have a release now and goals later than no release now and goals later ! and In future, we should make releases _without regard to long term goals_. Since we have to be incrementally-upgradeable, long term goals can be achieved just as easily out of step with releases. i (mostly) agree. debian's upgradeability is one of it's best features, and it is a feature which isn't matched by any other distribution...at least, not to the same extent. i've long believed that debian is a live distribution, and the best way to use it is to regularly (i.e. every week or two) upgrade to the latest unstablethis has worked for me for the last few years, and the only time i got bitten by a new bug enough to swear about it was when fmirror got upgraded to a bad alpha version and blew away my debian mirror (an expensive mistake at $0.19/megabyte). that's why i think we should have monthly untested snapshot CDs of unstable as well as regular tested official releasesso that those who don't have good net connections can benefit from debian's live nature. anyway, what i really wanted to say here was that sometimes releases do have to be delayed to meet some goals. i think that the upgrade to libc6 was one of them (but i think hamm met that goal around August or September last year, and could have been released anytime after that). I suspect that another such goal will be PAMit doesn't do much good to have half a PAM-enabled system. For PAM, we need all the typical login authentication stuff linked against PAM and we also need PAMified versions of sendmail, smail, etc so that mail can be delivered for users who only exist in a radius or LDAP directory and not in /etc/passwd. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release management - technical
Why? We could have both versions of these programs around for some time. For instance we add a login-pam package so whoever wants can work with it. Once all packages have their -pam package we can switch over to fully pam support. Or we could put the pam aware packages into experimental. Michael -- Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -Original Message- From: Craig Sanders [SMTP:[EMAIL PROTECTED] Sent: Monday, June 22, 1998 4:17 PM To: Ian Jackson Subject:Re: Release management - technical anyway, what i really wanted to say here was that sometimes releases do have to be delayed to meet some goals. i think that the upgrade to libc6 was one of them (but i think hamm met that goal around August or September last year, and could have been released anytime after that). I suspect that another such goal will be PAMit doesn't do much good to have half a PAM-enabled system. For PAM, we need all the typical login authentication stuff linked against PAM and we also need PAMified versions of sendmail, smail, etc so that mail can be delivered for users who only exist in a radius or LDAP directory and not in /etc/passwd. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release management - technical
On Mon, Jun 22, 1998 at 01:38:21PM +0100, Ian Jackson wrote: Enrique Zanardi writes (Re: Release management - technical): On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote: ... I think we can only do one of these. With hamm we're doing the latter; in the future I think we should do the former. Fine, as long as we have some long term goals that must be achieved, better sooner than later (FHS compliance, for example). NO! Absolutely not, if you're going to say `must be achieved'. I read `must be achieved' to mean `we will delay the release if these are not achieved'. Oops. That's not what I wanted to express. Long-term goals shouldn't delay the release. We are a volunteer organisation, and the last 13 months have shown us that you can't guilt people into doing things. We should continue to have `long term goals', and I applaud people who work towards them, but we must be able to make a release even when they are not met. It is better to have a release now and goals later than no release now and goals later ! I agree. An example of long term goal is apt. We want to substitute dselect with apt eventually, and there is a group of volunteers working towards it, but that goal won't delay hamm's release.. -- Enrique Zanardi[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release management - technical
At 5:38 AM -0700 6/22/98, Ian Jackson wrote: David Engel writes (Re: Release management - technical): On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote: Q. What are we trying to achieve ? A. There are two possibilities that I can see - Timely and good-quality releases, or - Releases which meet some predefined set of goals. In future, we should make releases _without regard to long term goals_. Since we have to be incrementally-upgradeable, long term goals can be achieved just as easily out of step with releases. Timeliness and good-quality are definately seperate goals, as any QA manager will attest to. Regards, -- -- Grant Bowman [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
