Re: completeness of the upg tests
On Sat, May 29, 2010 at 12:34:38PM +0200, C. Gatzemeier wrote: Thank you Harald for scrutinizing. Am Fri, 28 May 2010 14:50:27 +0200 schrieb Harald Braumann: If that externel system means to have UPGs, but does not support propper ID allignment (like debian, at least in the last releases), one will have to fix it or set a fixed umask, yes. ACK Same can be true in cases where a custom site-wide UPG user database is used. In this case, exactly as you wrote, manually setting a default umask is an option, if the IDs are not alligned or the user is explicitly added to his primary group. ACK And in those cases where it fails, I'd expect it to fail only for specific cases that might go unnoticed for a long time and might be hard to analyse. It's probably better if these are cases where the umask hasn't been relaxed, than cases where a fixed 002 umask is to permissive. This is a case for the 022 default with usergroups relaxation. Then if one has UPGs, but notices the umask is not 002 for some users, one checks login.defs and is informed about the checks and given a way to set a fixed umask. ACK However in case the external System properly supports alligned IDs (RH, etc.) I currently don't see where any rare cases of misbehaviour in either way should come from. The tests should work equally well even with mixed usersgroups. Just like on the external system itself. ACK If the external user database is non-UPG, this is the case where the tests prove most useful and provide security over setting a system wide 002 umask as a default. (Additionally it is a case where the admin can choose to turn umask relaxation off for peace of mind.) ACK To shield against any cases of username==groupname (say a vip user and group, or any other case of matching initials) where only coincidently UID==GUID match, I asked to check if vip is the primary group of the vip user and vip user is not an explicit member of the vip group. I believe this completes the checks (see below) I don't, and that is what I meant by wishful thinking. Nowhere is it guaranteed that it works this way. Even if there where guarantees by POSIX, which I'm not aware of, you could as well authenticate against an Active Directory or a Lotus Domino Directory exported as an LDAP tree or some directory that is managed by homegrown scripts. Does it work that way there? pam-umask's usergroups options does the right thing in many cases. But only the admin can know if the user database conforms to the necessary critera. And in that case, he can enable it and use it for automatic umask relaxation. But it shouldn't be the default if you can't guarantee that it works in all cases, and you can't. Yes, it is a slight inconvenience that you have to explicitely enable it for the many systems where it will work. But that is very often the case: that you trade convenience for security. It always depends on your priorities. If your priority is convenience, you will use auto-detection. If your priority is security, you will keep 022 as default umask and don't use auto-detection on default. Cheers, harry -- 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/20100531101754.gb4...@sbs288.lan
Re: test if primary group, with only implicit membership of the user?
On Sat, May 29, 2010 at 03:49:25PM +0200, Petter Reinholdtsen wrote: [Harald Braumann] Why would you create such a mixed system? I don't see a usecase for that. You should not really allow your lack of imagination to limit what computer systems can handle. :) Here at the University of Oslo, the user database is probably 25 years old, and some users have private groups as their primary group while others have shared groups. Of course the system should be flexible enough to support such legacy systems and even systems I can't imagine. And it is, and that's a good thing. I just meant that Debian doesn't have to deliver ready-made solutions for all possible imaginable and unimaginable set-ups. Cheers, harry -- 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/20100531102754.gc4...@sbs288.lan
Re: test if primary group, with only implicit membership of the user?
On Fri, May 28, 2010 at 11:30:25AM +0200, C. Gatzemeier wrote: I'm not sure yet, if I do properly understand the point when/why relaxing conditionally is a bad idea. To me, setting *fixed* umasks with group permissions equaling user permissions seems worse, especially because not all users of a system need to be set up with UPGs. Why would you create such a mixed system? I don't see a usecase for that. If the system is UPG it should be UPG for everyone. You can always add users to additional groups and use setgid directories. There is really no need to make some users non-UPG. So I don't think this needs to be supported out of the box. I think for an inappropriate relaxations to occur, the user/group info would have to come from some external system. And that is exactly the problem. If users are managed locally, you don't need any fancy auto-detection, because you know the system is UPG. The default for USERGROUPS is yes in /etc/adduser.conf. If the admin changes this, you can also expect him to change the default umask. But if users are managed externally, then nothing is guaranteed. All the assumptions about name or id equalities are nothing more than that: assumption. Therefore this autodetection will fail for all systems that don't conform to pam-umask's idea about user and group set-up. And in those cases where it fails, I'd expect it to fail only for specific cases that might go unnoticed for a long time and might be hard to analyse. So anyone with some conscience for security will immediately disable this source of indeterminism and set the umask to a fixed value. I know I will. So one thing is the change of the default value. I'd say keep the default at the most secure value. But the world won't end if it is changed. You just shouldn't forget to change it if you change USERGROUPS to no or use external user management. But the other thing is this auto detection that is only based on wishful thinking and just adds complexity and indeterminism. I'd really rather Debian wouldn't do this. Cheers, harry -- 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/20100528125026.ga4...@sbs288.lan
Re: The story behind UPG and umask.
On Thu, May 27, 2010 at 11:35:34AM +0200, Wolodja Wentland wrote: On Wed, May 26, 2010 at 23:43 +0100, Stephen Gran wrote: This one time, at band camp, Roger Leigh said: How will adduser cope with group addition; does it skip UIDs until it finds an unused unique UID/GID pair? That certainly is the only approach that makes sense - it has the benefit of simplicity, if not elegance. Agreed, but why not make the decision to use UPG explicit by setting UPG = True in a suitable configuration file in addition to each of the discussed heuristics? Or, just set umask to a fixed value. Cheers, harry -- 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/20100527111454.ga20...@sbs288.lan
Re: lilo removal in squeeze (or, please test grub2)
Hi, On Sat, May 22, 2010 at 10:39:52PM -0500, William Pitcock wrote: (4) Users need to test grub2 now. I've been using grub2 for quite some time now on several different systems with mixed success. On simple standard system -- one disk, one kernel in /boot, no fancy stuff -- it works quite well. On other systems it often breaks miserably. Updates leave my system unbootable every other time. One major problem are incompatible versions of the boot loader installed in the MBR and grub.cfg. Currently, automatic installation of grub in the MBR is a no-go for me, because of #554790 but I can't prevent grub from automatically updating grub.cfg which leads to incompatible versions, hence an unbootable system. On some systems the generated grub.cfg is useless for me. On each update I have to check for changes and incorporate them in my own hand-edited version. It is my belief, that the whole automagic configuration system as it is now is far to complex and convoluted. It is too inflexible to support any requirements by the user the developers haven't thought about and in this case you have to work actively against the system to get what you want. See #578576. I'm not sure if this can be fixed or if the whole system has to be rethought. Currently I'd tend to the latter. And because of the tight dependency between the loader and grub.cfg and zero-tolerance of the loader to unknown parameters in grub.cfg, it is far too fragile and very easily leads to an unbootable system. Because of this, coupled with the many open bugs and the lack of documentation, I'm not sure if grub2 is ready to be released to the unsuspecting public. Cheers, harry -- 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/20100525090027.ga30...@sbs288.lan
Re: The story behind UPG and umask.
On Tue, May 25, 2010 at 10:09:35PM +0200, C. Gatzemeier wrote: The path into your home directory is not restricted, just as the path others can take to ring your bell at home is not restricted. Depends on adduser settings. Both, world readable and private home directories are common. All this can work because the primary group of each user is set to a private user group (UPG) by default. This is a bold assumption. In a system where user management is external (e.g. LDAP), anything is possible and there are no defaults. According to [1,2] a UPG is identifiable by This is wrong. There is no way to differentiate UPG - non-UPG. But I'm repeating myself ... Cheers, harry -- 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/20100525204751.gb30...@sbs288.lan
Re: UPG and the default umask
On Tue, May 18, 2010 at 10:08:17AM +, Philipp Kern wrote: On 2010-05-18, Christoph Anton Mitterer cales...@scientia.net wrote: Not to speak about, that UPG is anyway a questionable abuse of the user/group concept. Neither to speak about the fact, that in the 17 years debian exists now,... no majority missed that feature (apparently). So you present that as universal facts as if you've booked the truth (possibly a bad translation of a German saying). I think that feature is useful for all those who don't want to mess with ACLs. If you are not allowed to use ACLs and don't have UPG with sane umasks collaboration is painful (see e.g. Debian infrastrure with all users being in group Debian and default umask 0022 which leads to wrong permissions in setgid directories, with ACLs being disallowed). So indeed I got a script which does newgrp and setting the umask for me which I run whenever I want to do release tasks. But it would be more sane if the user wouldn't have to care about that. Let me quote from the comments in /etc/login.defs: # 022 is the historical value in Debian for UMASK when it was used # 027, or even 077, could be considered better for privacy # There is no One True Answer here : each sysadmin must make up his/her # mind. And that's exactly the problem: there is no one-size-fits-all for the umask. Yes, for collaboration in a setgid directory you'd have to use 002 and thanks to UPG this is possible without compromising security. But I consider this just a special case. There are cases where Debian runs in a non-UPG environment, where you can't use that umask. And I don't think that's uncommon. Think of a mixed environment with Windows, where you might have a samba domain in LDAP. And last time I checked, the smbldap-tools didn't support UPG. So whatever value is used as the default, half of the users will have to change it anyway, to fit their needs. And in such a case, where there is no single optimal value, I'd rather have the most conservative as default. If the umask is 022 and you create a setgid directory and forget to change the umask, you will quickly realise that things are not working as expected and fix it. If the umask is 002 and you add your Debian system to a non-UPG environment and forget to change the umask, things will still work perfectly but you put all your files at risk and might not even realise it until it is too late. Cheers, harry -- 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/20100518131240.ga4...@sbs288.lan
Re: UPG and the default umask
On Tue, May 18, 2010 at 03:40:06PM +0200, Bastien ROUCARIES wrote: On Tue, May 18, 2010 at 3:12 PM, Harald Braumann ha...@unheit.net wrote: On Tue, May 18, 2010 at 10:08:17AM +, Philipp Kern wrote: On 2010-05-18, Christoph Anton Mitterer cales...@scientia.net wrote: Not to speak about, that UPG is anyway a questionable abuse of the user/group concept. Neither to speak about the fact, that in the 17 years debian exists now,... no majority missed that feature (apparently). So you present that as universal facts as if you've booked the truth (possibly a bad translation of a German saying). I think that feature is useful for all those who don't want to mess with ACLs. If you are not allowed to use ACLs and don't have UPG with sane umasks collaboration is painful (see e.g. Debian infrastrure with all users being in group Debian and default umask 0022 which leads to wrong permissions in setgid directories, with ACLs being disallowed). So indeed I got a script which does newgrp and setting the umask for me which I run whenever I want to do release tasks. But it would be more sane if the user wouldn't have to care about that. Let me quote from the comments in /etc/login.defs: # 022 is the historical value in Debian for UMASK when it was used # 027, or even 077, could be considered better for privacy # There is no One True Answer here : each sysadmin must make up his/her # mind. And that's exactly the problem: there is no one-size-fits-all for the umask. Yes, for collaboration in a setgid directory you'd have to use 002 and thanks to UPG this is possible without compromising security. But I consider this just a special case. There are cases where Debian runs in a non-UPG environment, where you can't use that umask. And I don't think that's uncommon. Think of a mixed environment with Windows, where you might have a samba domain in LDAP. And last time I checked, the smbldap-tools didn't support UPG. Could you fill a bug report against smbldap-tools ? There is already an upstream bug [0], but even if it get's implemented, that wouldn't magically change all systems out there running non-UPG So whatever value is used as the default, half of the users will have to change it anyway, to fit their needs. And in such a case, where there is no single optimal value, I'd rather have the most conservative as default. If the umask is 022 and you create a setgid directory and forget to change the umask, you will quickly realise that things are not working as expected and fix it. If the umask is 002 and you add your Debian system to a non-UPG environment and forget to change the umask, things will still work perfectly but you put all your files at risk and might not even realise it until it is too late. Why not add a security dialog and assistant for installing and upgrading the system? It will ease the transition and fit allt the need, documenting drawbacks and advantages of each scheme ? A umask of 022 is the right choice for most people and at least doesn't put the others at risk. Everyone, who knows what a setgid directory is and how it works, will also know, that there are certain requirements on the umask. And the others really don't care, as long as their security is not compromised. There is really no need to force everyone to make a useless decision, just for the sake of a change to make life of a specific minority easier. Cheers, harry [0] http://gna.org/support/?2040 -- 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/20100518141606.gb4...@sbs288.lan
Re: UPG and the default umask
If you want to answer, please do it on the list. I'm not interested in a private discussion. On Tue, May 18, 2010 at 04:23:24PM +0200, Bernhard R. Link wrote: * Harald Braumann ha...@unheit.net [100518 16:16]: There is already an upstream bug [0], but even if it get's implemented, that wouldn't magically change all systems out there running non-UPG We are not talking about system running non-UPG here. Were are talking about newly installed systems, thus UPG systems. There seems to be a widespread misconception, that there is only ever one isolated machine that does local user management. I think it is quite common in a network, to have users in LDAP or some other central database. If I install a machine in such an environment, it has to take whatever LDAP provides. I'm not going to change the whole user management, just for a newly installed Debian machine. A umask of 022 is the right choice for most people and at least doesn't put the others at risk. Please do not troll. I can not but yield to your conclusive argumentation and will from now on be quiet on this matter. In any case, I think I have presented all my arguments. harry -- 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/20100518193406.gc4...@sbs288.lan
Re: UPG and the default umask
On Thu, May 13, 2010 at 11:48:19AM +0200, Santiago Vila wrote: Will be done in base-files 5.4. I think that this change was done prematurely. There is still the issue of a Debian system running in a non-UPG environment. And so far I haven't seen a resolution for this point in the discussion. Cheers, harry -- 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/20100517102642.gd4...@sbs288.lan
Re: UPG and the default umask
On Mon, May 17, 2010 at 01:04:22PM +0200, Bastien ROUCARIES wrote: On Mon, May 17, 2010 at 12:26 PM, Harald Braumann ha...@unheit.net wrote: On Thu, May 13, 2010 at 11:48:19AM +0200, Santiago Vila wrote: Will be done in base-files 5.4. I think that this change was done prematurely. There is still the issue of a Debian system running in a non-UPG environment. And so far I haven't seen a resolution for this point in the discussion. I believe the pam umask module is the way to go according to http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-pam_umask.html Fair enough ... [opition] usergroups If the user is not root, and the user ID is equal to the group ID, and the username is the same as primary group name, the umask group bits are set to be the same as owner bits (examples: 022 - 002, 077 - 007). ... but that's the problem. User and group names/IDs are completely independent from one another and from the group regime emplyed. By no stretch of imagination can I see how you could deduce the group regime of a system from those. - you could have a UPG system but a mismatch of IDs - wrong umask - you could have a non-UPG system but a user's name and ID happen to match those of the group - wrong umask - you could add more layers and check, e.g., if the user is the only member in the group. but more users could be added later making the first user's files writeable by those. No matter how much clever logic you put in there, there is simply no way to make this work reliably because it's based on wrong assumption. Computer programmes work best when they are based on sound logic. Let's not part with this tradition. Let's keep the umask fixed at 022 and let the user change it if he wants. Cheers, harry -- 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/20100517160223.ge4...@sbs288.lan
Re: UPG and the default umask
On Mon, May 17, 2010 at 10:14:28AM -0600, Aaron Toponce wrote: On 05/17/2010 10:02 AM, Harald Braumann wrote: - you could have a UPG system but a mismatch of IDs - wrong umask ID numbers, yes. ID names, no. If the user name maches the group name, IE: aaron = aaron, then the user matches the private group. If the match is not made, then umask 0022 should be in play. from pam_umask's description of the usergroups option: If the user is not root, and the user ID is equal to the group ID, *and* the username is the same as primary group name, the umask group bits are set to be the same as owner bits (examples: 022 - 002, 077 - 007). So if there is a mismatch of *either*, name or ID, then pam_umasks detects a non-UPG system, while it might very well be all UPG. Also, just because Debian's adduser happens to give the same name to the user as well as to his private group, this is not necessarily true in all system. You could have group names that are prefixed with grp, or whatever, but still have a perfectly valid UPG system. - you could have a non-UPG system but a user's name and ID happen to match those of the group - wrong umask If the username matches the group name, then you have a UPG system. And on what assumptions do you base this conclusion? Unless you created a user called devel and put him in the devel group. Debian is not substitute for stupidity. How is that stupid? Users and groups are completely seperate name spaces, so why would I care in a non-UPG system? harry -- 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/20100517164957.gf4...@sbs288.lan
Re: UPG and the default umask
On Mon, May 17, 2010 at 11:04:58AM -0600, Aaron Toponce wrote: If you're using a non-UPG system, then you don't care. Debian is UPG-based, so your argument is invalid. So you propose that Debian should be restricted to work in pure UPG environments. Then there is no need to detect the environment and you can just set a fixed umask. If, however, we contemplate the thought that it might be desirable for Debian to continue to work in other environments, then I think my arguments are valid. And I think I have shown that it is not possible to detect the specifics of that environment. No matter how much magic you put into it. So again, you have to just set a fixed umask, because everything would just be esotericism and not based on any rational reasoning. Cheers, harry -- 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/20100517173746.gg4...@sbs288.lan
Re: UPG and the default umask
On Sat, May 15, 2010 at 02:34:57PM -0700, Russ Allbery wrote: Willi Mann foss...@wm1.at writes: Russ Allbery wrote: The purpose of UPG is not to use the user private group for any sort of access control. Rather, the point is to put each user in a group where they're the only member so that they can safely use a default umask of 002 without giving someone else write access to all their files. Is it possible to detect whether an account is configured properly based on the UPG idea? If yes, wouldn't it then make sense to only set umask 002 if a proper UPG account is detected, otherwise 022? This would avoid putting non-UPG systems on danger. That's a good idea. I'm not sure if all UNIX group systems allow one to ask how many users are a member of a particular group, but if there's a way to ask that question at least in those group systems that support it, the implementation should be fairly straightforward. To me this sounds more like heavy wizardry. Given the flexibility of pam this can at best be heuristical. Also it would change the umask from being a fixed value to being a dynamic value based upon some arbitrary global state. This would increase complexity and make it harder to reason about the system. Such changes should be avoided if there isn't a really good reason. And to make collaboration easier isn't a convincing reason, beacause the admin can easily change the default umask, already, if needed. I don't see a security problem with a umask of 002 in a UPG system and I also agree that it would be preferable in such a system. But the possibility of non-UPG systems is a valid concern. Therefore I'd opt to keep a default umask of 022. And don't try to be too clever figuring out what the umask should be. Keep it simple and let the admin decide on this. So on a system where collaboration should be supported, and the admin knows that it's a UPG system, he can set the umask to 002. It's not as if this was an overly complex task. Cheers, harry -- 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/20100516105939.ga4...@sbs288.lan
Re: UPG and the default umask
On Sun, May 16, 2010 at 03:11:56PM +, The Fungi wrote: On Sat, May 15, 2010 at 02:34:57PM -0700, Russ Allbery wrote: That's a good idea. I'm not sure if all UNIX group systems allow one to ask how many users are a member of a particular group, but if there's a way to ask that question at least in those group systems that support it, the implementation should be fairly straightforward. This is racy, unfortunately (at least by itself). Consider a non-UPG system which starts with one user... this check passes and files get created with group write flagged. Later, subsequent users appear sharing that same group and the default umask stops making new files group-writeable, but the first user's original files are now able to be modified by others (and then his account is immediately at risk of being taken over by one of the new users without his knowledge). Of course, coupled with other checks like uname==gname, parsing login.defs, et cetera, it could add an extra layer of assurance. I'd call it an extra layer of assumptions. I already get the shivers just thinking about the kind of complexity that is invented here. Now it's sufficient to have a look in /etc/profile to *know* the umask that will be set. If that scheme were implemented, I'd have to read code, several files and query ldap, or whatever is used, to *assume* what umask might be set. Please don't do that. If non-UPG systems should be supported, keep the umask at 022 and let the admin edit a single line to change it, if this is needed and he knows it's a pure UPG system. Cheers, harry -- 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/20100516205051.gc4...@sbs288.lan
Re: Open then gates
On Sat, May 15, 2010 at 12:53:30PM +0200, Christoph Anton Mitterer wrote: On Fri, 2010-05-14 at 22:22 -0700, Russ Allbery wrote: These are really odd complaints to bring against Debian given that these are not Debian issues. Firefox, for example, works exactly the same way everywhere. What do you want Debian to do, write our own web browser? There are limits to what a distribution can do. Again, these are just example where things could be secured I do of course not want to Debian write it's own browser, but we already patch some of them quite heavily, don't we? E.g. firefox to support all the plugin-packages stuff? So your argument is, that it must be insecure because other things are insecure? For example, here, you don't appear to understand that we're talking about the user umask, which should not be affecting system services, should not... well... I guess this isn't a proof, is it? You claimed that it would, so it is up to you to prove you're right, not the others to prove you're wrong. We've had so many examples of things that happened although they should not. udisks should have probably not exported the dm-crypt keys to normal users, but it did. Many scripts (don't remember a concrete example now) should have probably set a secure PATH, but they forgot to do so, and were attackable. sudo should have probably been secure, but it wasn't and if we would have added normal users to sudoers (like Ubuntu does as far as I know), everything would have been vulnerable. The openssl issue should have probably just solved some valgrind errors (wasn't that the idea of those patches?) but it lead probably to the great disaster in cryptography in the last years... Again, a random list of problems that have no correlation whatsoever with UPG and umask. If regular users can add other people to groups on your system, you have way more serious security problems than user-private groups, and those security problems are not created by Debian. Of course I talk about having this done by root. It seems you do not have experience with systems with several thousands of users, do you? If I'm e.g. a root user at my university, or an empowered registration authority for CERN,... I really cannot check whether what my users ask is sane. If user B says, please add user A to my group... I'll do it as long as no system user/group is involved. So your argument against something that is secure by default is that you could make it insecure by doing a really brain-damaged thing? Of course having a umask of 022 doesn't really prevent you from doing stupid things, so I don't see how it would improve security in this specific instance. Not to talk about the fact what happens, if at one day one wants to move away from UPGs... Right, lets not talk about that, because it is completely irrelevant for the current discussion. And here, you appear to have completely misunderstood the purpose of user-private groups in exactly the way that I tried to explain earlier. If there is anyone in a user-private group other than the user corresponding to it, you have broken user-private groups and created a security hole on your system. Yes I know... (the concept of them is really not so difficult to understand, is it?) But that's your misconfiguration, not something Debian did. Honestly,... real world is different... see my example above in big organisations, consider the fact that users have typically no idea what they doing... That's why they don't have the rights to change their group. If root has so little idea of what he's doing that he adds other users to a UPG, then quite honestly he should consider the possibility that he has chosen the wrong line of work. And even if you don't consider... What we had now, was already kind of semi-UPGs wasn't it? - Everybody had his private group, which others could be added to. No. You never add others to a UPG. So the following points are moot. - But if others were added, they did not automatically have rwx-rights on basically everything. With a default of 022: The owner of the file has to manually decide to make a file writeable by the members of his UPG, right? Isn't that much secure as the other way round? With a default of 077: It'd be even better, as the owner does not only have to deliberately decide for write, but also for read rights. and every distribution picks something and leaves that to site policy, rightfully. 022 is the standard default choice, and I think it's more appropriate for a free software distribution, although I know that by itself is a moderately controversial statement. IMHO, we generally should not do something, because any other distro is doing it. No, but we can learn from others' experiences. Do you know of any specific security problems in distributions that have UPG + umask 002? We should simply do the right. So let me make clear, that I don't decline
Re: Bug#540215: Introduce dh_checksums
On Fri, Apr 16, 2010 at 08:08:13AM +0200, Raphael Hertzog wrote: I'm discussing the case where the signature of the checksums file is valid but that checksums file does not list all the files present in data.tar.gz or control.tar.gz. Require that checksums exist for all files and let dpkg check that at installation time. But yes, I second your proposal for a DEP, instead of discussing details further in this thread, which has already become quite chaotic. harry -- 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/20100416113022.gc25...@sbs288.lan
Re: Bug#540215: Introduce dh_checksums
On Thu, Apr 15, 2010 at 05:03:44PM +0200, Raphael Hertzog wrote: Even if it creates a checksum file, someone could always hand-edit the package to add files not listed in the checksum files and we need to decide whether that's something that needs to be catched and if yes by whom and at what point. Do you mean a maintainer, who hand-edits a package after it was built, or do you mean an adversery who has evil intentions? If the former, then this should just be forbidden. If the latter, than this can be solved by package signatures. harry -- 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/20100416010251.ga25...@sbs288.lan
Re: Bug#540215: Introduce dh_checksums
On Thu, Apr 15, 2010 at 04:04:51PM +0200, Goswin von Brederlow wrote: The checksum file could be attached as additional member in the .deb. And a signature could be a signed file containing the checksum size and name of all members of a .deb preceeding the signature. That way the signature can verify the deb itself or individual members, like the checksum file, in the .deb. Just a thought. I'm not sure, how you mean that exactly. But the signature must be over the checksum file, nothing more and nothing less. Otherwise you won't be able to verify the checksum file. Also I think it's really a very bad idea in general to mix multiple different things into one signature. The one thing is a signature over installed files (via the checksum file). The other is a signature over a package. The two are completely orthogonal and serve different purposes. harry -- 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/20100416011001.gb25...@sbs288.lan
Re: Bug#540215: Introduce dh_checksums
On Fri, Mar 19, 2010 at 05:56:40PM -0700, Russ Allbery wrote: Harald Braumann ha...@unheit.net writes: On Thu, Mar 18, 2010 at 04:52:07PM -0700, Russ Allbery wrote: You add an additional ar member that contains the signed checksums of all of the files in data.tar.gz, possibly another additional member that contains the signed checksums for control.tar.gz, or you document some convention so that you can combine both into the same signed checksum document. Wouldn't it be simpler to just extract *sums from control.tar.gz, create a detached signature for it and put it in the ar archive, instead of extracting data.tar.gz and generating the sums a second time? Or would this replace dh_*sums during package build time? I think it would replace dh_*sums during package build time and make obsolete including md5sums in the control.tar.gz. You don't really want the signature and checksums to be inside one of the other data members since that breaks, as Wouter points out, the ability to remove the signature and checksums and verify against the original *.changes file. And there's no need to include two copies of the checksums. There would only be one additional file, containing a detached signature for the checksum file. No duplication of checksums and it can easily be removed from the ar. But doing everything in one step, like you proposed, is better anyway. And then create a second signature over all files in the ar archive directly. This one would be checked before extracting the containing tar.gz files, and the other one would be installed along with the *sums file. I think you want to checksum the underlying contents, not the *.tar.gz files in the ar archive. As Joey can attest to from writing pristine-tar, it's surprisingly difficult to reproduce a *.tar.gz file from its members. Misunderstanding. Forget what I said. To include checksums for control.tar.gz, just add them to the same checksum file, but with the paths, the files will have after package installation (/var/lib/dpkg/...). harry -- 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/20100320122752.gd1...@nn.nn
Re: Bug#540215: Introduce dh_checksums
On Sat, Mar 20, 2010 at 06:13:14AM -0700, Russ Allbery wrote: Yeah, that would be one such convention. I don't know if that's better or if adding a prefix of data: and control: to the path names would be better. My guess is that the latter may be a bit more flexible for possible long-term changes, like adding other deb members later for some reason that we want to sign. But aren't we talking about checksums of installed files here? So after package installation I'd like to have the file as /var/lib/dpkg/info/packag.checksums, just like the md5sums now, only that it's signed (preferably with a detached signature). This file has to be included verbatim in the package. You can't strip the data:/control: prefix on installation, as this would invalidate the signature. And it shouldn't be installed containing these prefixes, because then you can't use standard-tools to verify the checksums. If other stuff should be added later, for instance debsigs like signatures, then additional files can be added to the deb. I don't think it's wise trying to define a catch-all format now and I don't see why arbitray additional files for further extensions couldn't be added to the deb later. All these files could be packed together in, say, security.tar.gz, so you can always remove this single member from the ar to get the classic deb. harry -- 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/20100320154020.ge1...@nn.nn
Re: Bug#540215: Introduce dh_checksums
On Fri, Mar 19, 2010 at 09:14:13AM +0100, Frank Lin PIAT wrote: On Thu, 2010-03-18 at 12:39 +0100, Harald Braumann wrote: On Thu, Mar 18, 2010 at 08:31:40AM +0100, Goswin von Brederlow wrote: Russ Allbery r...@debian.org writes: Simon McVittie s...@debian.org writes: Most packages (in terms of proportion of the archive, in particular for architectures other than i386 and amd64) are built by a buildd, so each buildd would have to have a signing key that could sign the checksums file during build. Self-contained packages, where the signature is included and installed along with the checksum file, would have a lot of advantages. You wouldn't need access to a lot of infrastructure just to verify a signature. It would be very simple. It could be used for packages, that are not part of Debian. For instance, I could produce a package and send it to a friend and he could later use my key for verification. Oh please no. Don't advocate sending individual .deb files, ever. This practice should be strongly discouraged. One brilliant part of Debian packaging *is* the APT infrastructure, some key features: It's local software that's relevant for me and maybe 3 other people. I don't think Debian would accept it in the archive. And I'm not going to set up an APT infrastructure for this either, because it's simply not needed. If people and ISV start publishing individual .deb, they (and we) will have to face the same problem as Windows/Mac/whatever had to solve: each application will need to embed a feature to Check for update, etc. These are exceptions, it's not like suddenly everyone starts publishing their own debs. But why shouldn't an implementation also support this? harry -- 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/20100319102357.ga1...@nn.nn
Re: Bug#540215: Introduce dh_checksums
On Fri, Mar 19, 2010 at 10:38:24AM +0100, Goswin von Brederlow wrote: You can always sign the deb. The tools to sign and verify are all present. Only ftp-master stands in the way of using that. I would love signed debs. But this is orthogonal to signed checksum files and should probably discussed separately. And you could automatically download the changes files along with every deb and keep all changes files for installed package/version locally. Anyway, I don't consider a ftp/http client a lot of infrastructure. It would be trivial to write a tool that downloads the changes files for every installed package and verifies it. The central repository is the infrastracture, not the http client. All changes files are already kept. And you would go directly to fetching the changes file for the package/version you have installed. All it would need is for the changes file archive to become public. If the signature was part of the package, this wasn't needed. harry -- 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/20100319103042.gb1...@nn.nn
Re: Bug#540215: Introduce dh_checksums
On Thu, Mar 18, 2010 at 04:52:07PM -0700, Russ Allbery wrote: Frank Lin PIAT fp...@klabs.be writes: I have no strong preferences between signed APT and SIGNED DEBs... it is just that the remaining of the thread showed that signed DEBs are quite tough to implement. (and I still wonder how we could preserve the current deb format with tar.gz in ar, while signing the debs) You add an additional ar member that contains the signed checksums of all of the files in data.tar.gz, possibly another additional member that contains the signed checksums for control.tar.gz, or you document some convention so that you can combine both into the same signed checksum document. Wouldn't it be simpler to just extract *sums from control.tar.gz, create a detached signature for it and put it in the ar archive, instead of extracting data.tar.gz and generating the sums a second time? Or would this replace dh_*sums during package build time? And then create a second signature over all files in the ar archive directly. This one would be checked before extracting the containing tar.gz files, and the other one would be installed along with the *sums file. harry -- 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/20100320004007.gc1...@nn.nn
Re: Bug#540215: Introduce dh_checksums
On Wed, Mar 17, 2010 at 02:36:31PM +, Simon McVittie wrote: On Wed, 17 Mar 2010 at 12:41:58 +0100, Harald Braumann wrote: It should be signed at build time, just after dh_shasums and then the sig file packaged together with all the other files. I don't see a problem with that. Or maybe I'm not getting something here? Most packages (in terms of proportion of the archive, in particular for architectures other than i386 and amd64) are built by a buildd, so each buildd would have to have a signing key that could sign the checksums file during build. Further, the build part of a buildd runs inside a limited chroot running the target distribution, i.e. usually unstable (the real system runs stable with a backported version of sbuild), which doesn't have access to any key material in the real system. At the moment buildds don't have their own keys: a buildd maintainer inspects the build log and signs the .changes file for upload. Even for maintainer uploads, maintainers who build their packages in a minimal chroot with schroot, pbuilder, cowbuilder etc. (which is strongly recommended) don't necessarily have their signing key available inside the chroot (nor should they!). Thanks for explaining all these details. I build my packages with sbuild/schroot, and my GPG key isn't available inside the build system as a result of using gfcombinefs to split my key between my laptop and a USB stick (so that if either is stolen, my key isn't compromised). I'm told some developers take this further, and only store their key on a non-networked machine to which they transfer files for signing (the current package upload procedure makes this possible - they only really need to transfer the .changes file, in fact). I think it would be irresponsible to make it necessary for DDs to choose between weakening the security of their GPG keys, or producing less reproducible builds. Theoretically you could produce rather short-lived keys that are signed with your maintainer key, make those available in the build environment and use them for signing. The signing key along with the signature by the maintainer key would have to be included in the package as well. But I guess that this would be a tad to complex and I wouldn't propose it. harry -- 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/20100318110955.gb17...@nn.nn
Re: Bug#540215: Introduce dh_checksums
On Thu, Mar 18, 2010 at 08:31:40AM +0100, Goswin von Brederlow wrote: Russ Allbery r...@debian.org writes: Simon McVittie s...@debian.org writes: Most packages (in terms of proportion of the archive, in particular for architectures other than i386 and amd64) are built by a buildd, so each buildd would have to have a signing key that could sign the checksums file during build. Further, the build part of a buildd runs inside a limited chroot running the target distribution, i.e. usually unstable (the real system runs stable with a backported version of sbuild), which doesn't have access to any key material in the real system. At the moment buildds don't have their own keys: a buildd maintainer inspects the build log and signs the .changes file for upload. Even for maintainer uploads, maintainers who build their packages in a minimal chroot with schroot, pbuilder, cowbuilder etc. (which is strongly recommended) don't necessarily have their signing key available inside the chroot (nor should they!). Signatures per buildd or per DD doing uploads are moderately interesting, but not nearly as interesting as a signature by a long-term stable key such as the archive key. Do we actually rely anywhere on packages not changing hashes between upload and publication in the repository, or is it just something we have as an invariant now because there's no reason for it not to be one? The path of least resistance here would be for DAK to add the package signature after verifying the signature of the uploader. This has the drawback that it modifies the *.deb and therefore breaks the hashes in the *.changes file and hence its original signature, but given that we throw out the *.changes file anyway, do we actually care? The changes files are afaik archived somewhere and are needed to verify the archive integrity after a (feared) compromise. And what do you do when the archive key expires? Resign every deb in the archive and have every mirror download them all again? Why? A signature doesn't become invalid just because the key expires, as long as the signature was created before the expiration of the key. Same problem on releases. Releasing a new stable means a new stable key so every deb needs to be signed again and changes. I don't think this is a good idea. This would also cause users (apt/aptitude actually) to reinstall the packages needlessly creating even more mirror load. For this to work the signature for the checksum files should be detached so that it can be changed/extended without altering the deb files. I suggested this before but lets repeat it. Why not include a digest of the checksum file in DEBIAN/control, carry it into the changes file and into Packages.gz. That way all current debs automatically have a clear trust path. Further the changes files could be included in the pool alongside the debs and source files. That way everyone can verify the autenticity of the debs (or just the checksum file) independent of the archive key. Going one step further the changes files could be signed by the archive key(s) as well. Adding a new signature to them when keys change does mean they need to be mirrored again but they are relatively small. Self-contained packages, where the signature is included and installed along with the checksum file, would have a lot of advantages. You wouldn't need access to a lot of infrastructure just to verify a signature. It would be very simple. It could be used for packages, that are not part of Debian. For instance, I could produce a package and send it to a friend and he could later use my key for verification. The same holds for projects that publish deb files. With your proposal they would need a full fledged archive and keep a long history of all the files. And what do you do with packages from testing/unstable/experimental? Would you keep all incarnations of the Release/Packages/changes files? And if I want to verify the signature of an installed file, from a package I once installed from, say, unstable, how would I find the right version of the changes file for the package? Cheers, harry -- 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/20100318113959.gc17...@nn.nn
Re: Bug#540215: Introduce dh_checksums
On Wed, Mar 17, 2010 at 08:58:28AM +0100, Goswin von Brederlow wrote: I don't think signing the checksum file itself will be feasable as that would alter the contents of the deb and change the checksums in the changes files autobuilders send the admin for signing. It would break the existing signing infrastructure for autobuilders. It would also require running dpkg-genchanges again during signing or otherwise adjust the checksums in the changes file. It should be signed at build time, just after dh_shasums and then the sig file packaged together with all the other files. I don't see a problem with that. Or maybe I'm not getting something here? Cheers, harry -- 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/20100317114158.ga17...@nn.nn
Re: Bug#540215: Introduce dh_checksums
On Wed, Mar 10, 2010 at 03:32:14PM +0100, Wouter Verhelst wrote: Having package.checksums be GPG-signed will take a significant change in our infrastructure (buildd hosts, for instance, would need to have a way to sign checksums files as well), so it's not going to happen tomorrow. I was wondering about that. Unfortunately I'm quite ignorant of the details of the whole upload and build process. - Are all packages that end up in the archive built by the autobuilders, or can maintainers upload binary packages directly? - How are the Release files signed? Is it done automatically or manually? By whom? Cheers, harry -- 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/20100311173710.gc25...@nn.nn
Re: Best practices for OpenPGP keys?
On Wed, Mar 10, 2010 at 09:44:03AM -0600, Drew Scott Daniels wrote: Hi, Is there any good documentation about best practices for OpenPGP key management? I plan to use gnupg (gpg), as it's conventional and seems like the best of breed these days. Most documentation I've found seems significantly out of date (including long discussions of incompatibilities with versions from 2001...). I did find it interesting that the IDEA patents are expiring in May this year for the EU and US if I remember The best documentation I have found includes: http://arfore.com/2007/07/29/gpg-best-practices/ http://www.cam.ac.uk.pgp.net/pgpnet/pgp-faq/ Sorry, can't help with specific documentation. The main problem I see is the passphrase for your private key. Because what does it help, if your key is ultra long, but then your passphrase has an entropy of just 20 bits? And a passphrase with an entropy of 128 bits is impossible to remember. I find the best trade-off between security and convenience is to store the key on a smart card. The key would be locked/destroyed, if the passphrase/PIN were to be entered wrongly 3 or 4 times. This solves a lot of problems: - the passphrase/PIN can be short and thus easy to remember - your key can't be stolen without you noticing it, so no offline cracking attempts are possible, and even if someone were to know your passphrase, he still would have to get your card (though someone could borrow it without you noticing). Though of course other problems remain: - someone could sniff your PIN between the keyboard and the card. you'd need an EPP (encrypting PIN pad) that works together with the card. - if you sign a document, you can never be sure, if the document, that you see on the screen is really the one that is actually signed. So it still holds, that the machine on which you use your key should be secure. Over the years I've heard some ideas like: * Only store your key on less common architecture to make break-ins involve more esoteric techniques (e.g. common rootkits/scripts fail). A variant of this would be adding a level of virtual abstraction by using a virtual machine (though it's just a level of obfuscation). * Set an expiry date on your primary key and/or sub-key and sign a new key before the old key expires. I think this is problematic for some key reading programs though I can't remember any instances. Expiry dates aren't default and seemed to be uncommon last time I checked. I never thought, expiry dates were uncommon, on the contrary. Care to elaborate? * Revoke primary and/or sub-keys after expiration, or instead of expiration. While revoking keys can keep people from using the old key even if they cracked it, many programs might expect that revoked keys aren't trustworthy at all. Revocation has a very serious problem: you can never be sure if everybody else knows about it. * Use a really long keylength for your sub-key. The trade off seems to be that signing and encrypting things takes a lot longer. * Use a really long keylength for your primary key and Well, it doesn't have to be really long. Last time I checked the consesus was that 1024 bits (for RSA) is now considered to short for long-term security. 2048 are suggested. I use 4096, because I can. Performance is no issue with current average computing power. You might have to make trade-offs, if embedded systems or some such are involved. * Don't store your key on machines that connect to any networks. Transferring signed data is time consuming, inconvenient... I'm not sure if it's fair to say it's vulnerable to social engineering attacks. * Use a random string for your passphrase. I was bit by this on my first attempt to use a keypair years ago (around 2003). I forgot the passphrase. * Harden machines that contain your private key. While it's usually a good idea to do this for all machines, I would hope that most things would be secure without having to spend the extra time doing configurations... Keeping the machines secure is always a good idea. But usually you trade convinience for security. Only using a non-networked machine, locked away in vault, is probably far too much trouble for the general use-case. harry PS: I think that this is really off-topic for debian-devel -- 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/20100311182503.gd25...@nn.nn
Re: Bug#540215: Introduce dh_checksums
On Mon, Mar 08, 2010 at 10:49:54PM -0500, Joey Hess wrote: Russ Allbery wrote: It's also always worth bearing in mind that while a really good attacker can do all sorts of complex things that make them very hard to find, most attackers are stupid and straightforward. It's stupid and straightforward to install /usr/local/bin/ls. debsums will not detect it. And it's as straightforward to find files which don't belong to any package and have some other means in place to check locally generated files. If I understand you correctly, you argue that one would need some IDS anyway to cover all files, and that could then be used also to verify package files. Therefore making file signatures in packages superfluous. I think I could agree with that. On the other hand, I tend to keep /usr/local clean and create packages for for home-grown software. If you do this consistently, you'd get a system where you could verify all files without additional software (modulo the script that checks for surplus files). More important would be package signatures, anyway, because currently there is no way to verify a package. I work with testing/unstable a lot and often I have deb files lying around are not in any Release, so there is no way of verifying them. harry -- 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/20100309125920.gc15...@nn.nn
Re: Bug#540215: Introduce dh_checksums
On Tue, Mar 09, 2010 at 10:50:59AM -0600, Peter Samuelson wrote: [Frank Lin PIAT] Please, let's do the easy move *now* for Squeeze, using shasums, and go ahead later with an even better solution. Drawbacks: more CPU time on build daemons, slightly larger binary packages to download, and some disruption when we're trying to get a release out the door. Advantages: ... umm ... warm fuzzy feeling that we aren't relying on that old stupid broken MD5 thing that is so out of fashion these days among the cognoscenti? If you really want to use /var/lib/dpkg/info/pkg.*sums files for any purpose other than detecting non-malicious corruption, obviously you need _either_ some form of package signatures, _or_ a server akin to http://packages.debian.org/changelogs/ for serving checksums from a more trusted source. And of course if you have that sort of server support anyway - why not just calculate those sha16384 sums on the server, with no change to the debs at all? See, you don't need a server. You just ship a signature over the hash files. Easy as that. Of course the hashes would neet to be something more secure than md5, for that warm fuzzy feeling that in two years time not every script kiddy can mount hash attacks on their home computer. harry -- 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/20100309183541.ga25...@nn.nn
Re: Bug#540215: Introduce dh_checksums
On Mon, Mar 08, 2010 at 11:04:24PM +0100, Frank Lin PIAT wrote: On Mon, 2010-03-08 at 12:59 -0800, Russ Allbery wrote: 1. Strengthen the integrity check so that it could potentially be useful for security purposes as well as for simple integrity checking. It would be much easier if a signed list of check-sums for current packages in our archive were published (basically, when we create Packages.gpg, we would need to extract the checksums contained in those packages, then sign it. This list could also included the recently updated packages, which is useful for point-releases, and unstable). I'm a bit confused here. I think that here is a mix of package signatures and file signatures. These serve different purposes and are completely separate. A package signature lets you verfy the package before it is decompressed and, more importantly, maintainer scripts are run as root. File signatures let you check the installed files. Both should be part of the shipped package. Package signature as files in the arch archive, file signatures should be installed along with the files so you can always directly check installed files, without the need of any repository or original packages lying around. The benefit is that you can quickly audit if installed binaries are pristine AND current. If we take option 1, going to a stronger hash is strictly less useful in every respect than going to embedded PGP signatures Assuming file hashes here: create stronger hashes and then sign the hash file. This has 2 advantages: - hashes can be used to check file integrity even without the key - it can be implemented incrementally (1st: stonger hashes, 2nd: signature) which apparently only require active maintenance and a plan to be acceptable in the archive and which would need a different format anyway. Assuming package hashes here: a view additional files in the arch archive. I see some problems with signed packages: 1. Software developers and vendors will start distributing standalone binary packages, and pretend they are safe because they are signed. This is not safe: only an APT-like mechanism provides security updates. Yes, there seems to be a common misconception about what a signature means. But that's no argument to deny informed people the advantages of signatures. 2. You still need an infrastructure to publish valid packages version. Isn't that the Release file? 3. What do we do when we want to change a GPG key? we re-sign all the packages, probably breaking existing packages checksums? No, the signature has a timestamp and is still valid, if the revocation date of key is later. Last but not least: 4. How long is it going to implement it? Does it seems realistic to implement your proposal before Squeeze +1 (or event Squeeze +2)? What do we do in-between? If we take option 2, SHA256 offers no benefits over MD5 and just takes longer to compute. Why is that everyone seems to move away from MD5? Because it's broken? There is essentially zero chance that random file corruption or typical local modification will result in a successful MD5 preimage attack. An attacker has plenty of time to pre-compute a valid replacement for, let say, a library in Debian Stable. I therefore have to question what utility there is in switching to SHA256. It doesn't seem to achieve either possible goal, unless I'm missing some way in which it's a step towards option 1? See above. As a bottom line: 1. A package is not safe because it is signed, but because it is up-to-date. A signature hasn't got anything to do with how safe a package is. harry -- 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/20100309033126.ga15...@nn.nn
Re: Bug#540215: Introduce dh_checksums
On Mon, Mar 08, 2010 at 05:59:13PM -0500, Joey Hess wrote: Russ Allbery wrote: The missing link, in this validation scenario, is how to get a signed copy of the MD5 checksums of the files in the package. That's one missing link. The other one is that there are innumerable ways for an attacker to inject bad behavior/backdoors onto a system without touching binaries originating from dpkg. Signatures don't prevent bugs, they don't prevent trojans, they don't prevent attacks on SSH. But they let you *detect* attacks. It's not that easy to install a root kit that hides all changes and you can always boot from a trusted medium to check your files. Without signatures, you can't, or at least it a lot harder. Expecting debsums to protect against any form of attack is bound to result in a false sense of security; I don't expect that. harry -- 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/20100309033842.gb15...@nn.nn
sensible-mailer
Hi, I'd like to propose a `sensible-mailer' command. The main usage would be to handle `mailto' links. But maybe such functionality already exists and I'm just not aware of it, or there are specific reasons for not implementing this. The script should accept a `mailto' link as its parameter and then invoke whatever MUA the user has configured through an environment variable. MUAs that don't support these links out of the box (like mutt) should provide a helper script that parses the URL and invokes the mailer with appropriate options. Web browsers could be configured to use this command out of the box. Additionally the command could provide a minimum set of options (like `--to', `--subject', `--cc', ...) that would allow to invoke it manually and start the user's MUA with these parameters pre-filled. Any thoughts about this? Cheers, harry -- 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/20100305140628.gc21...@nn.nn
Re: sensible-mailer
On Fri, Mar 05, 2010 at 03:30:45PM +0100, Giacomo A. Catenazzi wrote: On 05.03.2010 15:18, Josselin Mouette wrote: Le vendredi 05 mars 2010 à 15:06 +0100, Harald Braumann a écrit : I'd like to propose a `sensible-mailer' command. The main usage would be to handle `mailto' links. But maybe such functionality already exists and I'm just not aware of it, or there are specific reasons for not implementing this. xdg-open handles mailto links just fine. not guaranteed: from manpage: xdg-open supports file, ftp, http and https URLs. It's xdg-email. It has exactly the interface that I would envision, but alas doesn't work. Not the whole world is a desktop. If it doesn't detect any of the desktop environments, it will call sensible-browser, which leads you back to where you've started (the browser, where you clicked the link). So we would still need a sensible-mailer command, that can be called in such a case. It's also necessary to convert the link to command line options for mailers that don't support mailto links. harry -- 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/20100305144355.ge21...@nn.nn
Re: sensible-mailer
On Fri, Mar 05, 2010 at 03:10:26PM +0100, Samuel Thibault wrote: Harald Braumann, le Fri 05 Mar 2010 15:06:28 +0100, a écrit : I'd like to propose a `sensible-mailer' command. Well, there is /etc/alternatives/mailx You can't set, e.g., mutt as an alternative. Also the problem with the alternatives system is, that it's a system wide setting and doesn't allow the use to change his alternatives. harry -- 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/20100305144702.gf21...@nn.nn
Re: sensible-mailer
On Fri, Mar 05, 2010 at 04:46:40PM +0100, Yves-Alexis Perez wrote: Le 05/03/2010 15:43, Harald Braumann a écrit : On Fri, Mar 05, 2010 at 03:30:45PM +0100, Giacomo A. Catenazzi wrote: On 05.03.2010 15:18, Josselin Mouette wrote: Le vendredi 05 mars 2010 à 15:06 +0100, Harald Braumann a écrit : I'd like to propose a `sensible-mailer' command. The main usage would be to handle `mailto' links. But maybe such functionality already exists and I'm just not aware of it, or there are specific reasons for not implementing this. xdg-open handles mailto links just fine. not guaranteed: from manpage: xdg-open supports file, ftp, http and https URLs. It's xdg-email. It has exactly the interface that I would envision, but alas doesn't work. Not the whole world is a desktop. If it doesn't detect any of the desktop environments, it will call sensible-browser, which leads you back to where you've started (the browser, where you clicked the link). So we would still need a sensible-mailer command, that can be called in such a case. It's also necessary to convert the link to command line options for mailers that don't support mailto links. Please no, not another one or we'll end up with the browser situation (sensible-browser, gnome-www-browser, www-browser, x-www-browser, WTF?). xdg-email (or even xdg-open, fwiw) would definitely be the correct solution, that way the user can set the mailer he wants. Make it have a good default (a $MAILER better than a new command, imho) and you're done. Fair enough. That seems to be sufficient and also the simplest solution. I just found out, that xdg-email calls xdg-email-hook.sh, if it is found in the path. So it seems everything is there already. I'd prefer a variable, but that's just a minor detail. Thanks all for the input. Cheers, harry -- 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/20100305171400.gg21...@nn.nn
Re: Removing the manpage requirement for GUI programs?
On Thu, Mar 04, 2010 at 10:40:57PM +0900, Charles Plessy wrote: Hello Josselin and everybody, I concur to much that has been written about obsolete manpages. In the past I often wrote manpages for my new packages, and in many cases they became a burden for me as a package maintainer when they did not get adopted upstream. Now my current point of view is that if there is no manpage, it is too often because the upstream author is not interested in writing and maintaining a manpage. Moreover, the nroff markup sytem is more suited to write novels than computer documentation (unless you like to put a backslash in front of every minus sign), so I use an intermediate format (usually DocBook), and in my experience, this source is often discarded, which makes it more difficult for me to help upstream to keep his manpage up to date. As a result, I do not write manpages anymore. I'm one of those who think that a man page, that just says This programme does this, for more information look there is better than no man page at all. It helps those who think like me, it wouldn't put too much burden on the maintainer and I don't see how it would do much harm to those, that think such a page minimal page is useless. help2man is not the silver bullet either as it does not work on every help outputs. And if the goal is to be able to know about programs that are being run in the computer, the current policy is not enough anyway since some of them actually reside in /usr/lib or /usr/share, which are places out of the scope of Policy §12.1. I recently prepared a patch to the package for rtmpdump for a new upstream version. Command line options changed a bit and so the man pages had to be adapted. The help output of the commands in this package produce a format that is almost but not quite as help2man expects it. The obvious idea was to filter it through a simple sed or awk script, but alas help2man insists on calling the command itself and doesn't accept input on stdin. So maybe a wishlisht bug for help2man is in order? If help2man was more flexible it might be useful in more circumstances. Still, it would be nice to be able to know about the purpose of the programs that are ran or stored on our computers. Would there be a way to hijack the whatis database of the man infrastructure for this, with for instance a section numero 0? A cheap solution would be to use manpages with only a NAME section. It would be trivial to write a helper script that is fed with a name and a one-line description, and that produces a Debian manpages. For programs with a GUI, the source of information could be the .desktop menu entry. It would have the great advantage that the information and the translations would be managed upstream. Until such tools are available, a minimal man page is IMHO a good solution. harry -- 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/20100304142458.ga21...@nn.nn
Re: md5sums files
On Wed, Mar 03, 2010 at 03:06:20AM +0100, Wouter Verhelst wrote: In this day and age of completely and utterly broken MD5[0], I think we should stop providing these files, and maybe provide something else instead. Like, I dunno, shasums? Or perhaps gpgsigs? But stop providing md5sums. Or is it useful to be able to say if it doesn't check out, it's certainly corrupt, and if it does check out, it may be corrupt? Didn't think so. As a means to check for filesystem corruptions or non-malicious changes, MD5 is good enough. So until we have something better, I guess they can stay. But it would be great if the whole chain, from beginning to end, was secured, even against a malicious and presumably very powerful attackers. That would need: * Package signatures Currently only the release file is signed, but if you have a package lying around, there is no way to check its authenticity. * Cryptographically strong hashes for all files in the package and a signature on the hash file. Then you could really check the authenticity of all files on the system. For the hash I would skip SHA-1 and move directly to SHA-256. Oh, and a good read about the lifetime of hash algorithms can be found here: [0] Cheers, harry [0] http://valerieaurora.org/hash.html -- 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/20100303133905.gb11...@nn.nn
Re: md5sums files
On Wed, Mar 03, 2010 at 03:16:08PM +0100, Bernhard R. Link wrote: * Harald Braumann ha...@unheit.net [100303 14:49]: But it would be great if the whole chain, from beginning to end, was secured, even against a malicious and presumably very powerful attackers. Checksums for files coming from packages is not really useful to defend against attackers (it's really only reliablity and not security): - an attacker can just divert any binary away and put it's own there. It's not about preventing an attack, but detecting it. With cryptographically strong hashes/signatures in place, you can audit the system. Of course you'd have to boot from a trusted medium. How would you do that without signatures? - an attacker can just add some additional binary where it will override another one (/sbin overriding /usr/sbin and so on). - an attacker can add things to configuration and startup files (thanks to .d directories you often not even need changing but only adding files), including search binary or library paths, so one could add binaries or behaviour changing libraries in directories not looking that suspicious. Yes, a full IDS needs additional work. It would have to check for files without hashes/signatures and would have to allow you to hash and sign files in /etc, /usr/local, /opt, whatever). Most of those things can perhaps be fixed, but it needs much work than just replacing some hash. (And many of those tasks might also improve other areas (like http://packages.debian.org/cruft also having the problem that packages create so many files and there is no way a package can tell such programs where they are). -- 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/20100303150337.gc11...@nn.nn
Re: md5sums files
On Thu, Mar 04, 2010 at 01:12:26AM +0900, Osamu Aoki wrote: In this day and age of completely and utterly broken MD5[0], I think we should stop providing these files, and maybe provide something else instead. Like, I dunno, shasums? Or perhaps gpgsigs? But stop providing md5sums. gpg is slow. sha variants will be nice if there is smooth transition in place properly planned and supprted with backported package of debsums. You wouldn't sign each file, just the hash sums file. harry -- 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/20100303175954.gd11...@nn.nn
Re: md5sums files
On Wed, Mar 03, 2010 at 02:02:01PM -0600, Peter Samuelson wrote: [Julien Cristau] fundamentally, shipping a md5sums file is really just a tradeoff in download size vs. installation speed, not unlike gzip vs. bzip2. One Only if you assume that disks never fail and thus files never get corrupted when the package gets unpacked. Given a .deb, turning the data.tar.gz into foo.md5sums is a SMOP. This could be before, during, or after the deb is unpacked. If you create the hashes at unpack time, you don't catch errors that happen during unpack. Why not create them at package build time and include them? I mean we are talking bytes here for the hashes, not megabytes. I can't see a download size problem. Using the packaged foo.md5sums as an internal consistency check of data.tar.gz itself is interesting, but somewhat unwieldy. Better would be to checksum data.tar.gz in its entirety. But doesn't gzip already do that? (Yes, it's only 32 bits, but we aren't trying to detect intentional tampering, only corruption. The hash must include the whole package, not just data.tar.gz. To detect intentional tampering, you need signed debs, Yes, I think that should be the goal. or at least signed Packages.bz2.) You already have this, kind of: the Release file is signed and it contains the hash of the Packages file, wich in turn contains the hashes for the packages. The problem here is, that you can only check packages, that are currently part in some release. If you have an old version lying around or a package sent to you by someone, you're out of luck. The package signature should be part of the package. harry -- 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/20100303204038.ge11...@nn.nn
Re: md5sums files
On Wed, Mar 03, 2010 at 04:20:36PM -0500, Michael Gilbert wrote:
On Wed, 03 Mar 2010 21:58:11 +0100, Frank Lin PIAT wrote:
Signed debs may introduce a fake sense of security (Only apt repository
provide security updates). By signing packages, user may assume that a
package is safe when it isn't.
it should actually be possible to do this securely. dpkg could be
made to work like apt where it only blindly trusts packages signed
by keys in /etc/apt/trusted.gpg. the downfall is that there is nothing
stopping the user from adding additional (potentially less than
trustworthy keys), but that isn't really solvable without destroying
freedom, and it isn't any different from the current state for apt.
Completely agreed. Also, because playing around is always more fun than
just talking, I've attached a script that signs/verifies binary
packages. Dpkg doesn't seem to mind the extra files.
This script signs each file in the package individually, but it could
also concatenate them all alphabetically and create just one signature.
Cheers,
harry
#!/bin/sh
usage() {
catEOF
Usage: debsign -s|-v debfile
Sign or verify Debian packages
-s sign
-v verify
EOF
}
sign() {
echo signing ${DEB}:${FILE}
ar p ${DEB} ${FILE} | gpg --detach-sign --output ${SIG} - \
ar r ${DEB} ${SIG}
}
verify() {
echo verifying signature of ${DEB}:${FILE}
ar p ${DEB} ${FILE}.sig ${SIG} \
ar p ${DEB} ${FILE} | gpg --verify ${SIG} -
}
[ $# -eq 2 ] || { usage 2; exit 1; }
DEB=$2
case $1 in
-s) OP=sign;;
-v) OP=verify;;
*) usage 2; exit 1;;
esac
[ -f ${DEB} ] || { printf %s\n ${DEB} not found 2; exit 1; }
TMPDIR=`mktemp -d --tmpdir debsign.XX`
ar t ${DEB} | while read FILE; do
[ ${FILE##*.} != sig ] || continue
SIG=${TMPDIR}/${FILE}.sig
${OP} || exit 1
done
RC=$?
rm ${TMPDIR}/* 2/dev/null
rmdir ${TMPDIR} 2/dev/null
if [ ${RC} -eq 0 ]; then
echo OK
else
echo Failed
fi
return ${RC}
Re: md5sums files
On Wed, Mar 03, 2010 at 03:14:04PM -0800, Russ Allbery wrote: Harald Braumann ha...@unheit.net writes: Completely agreed. Also, because playing around is always more fun than just talking, I've attached a script that signs/verifies binary packages. Dpkg doesn't seem to mind the extra files. This script signs each file in the package individually, but it could also concatenate them all alphabetically and create just one signature. See debsigs. Ah, thanks, good to know. There have been previous discussions on debian-devel about this. I believe DAK does not allow packages signed using debsigs to be uploaded. I'm not sure if that's out of objection to the entire concept, or whether there are just technical issues that need to be resolved first. (I probably would know if I had a better memory for the previous discussion, but unfortunately I appear to have recycled those brain cells.) Maybe this [0]? Also, it seems, that people have `discussed' it, and that there was experimental support in dpkg for it [1]. The proposal, that came out of this discussion is outlined in [2]. This was in 2000 ... I haven't found any specific reasons why it was never implemented. I guess the reason is just that it's hard to do. Not the technical side, but defining the processes. harry [0] http://lists.debian.org/debian-devel/2002/03/msg01484.html [1] http://lists.debian.org/debian-dpkg/2000/07/msg1.html [2] http://lists.debian.org/debian-dpkg/2000/07/msg00044.html -- 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/20100304000655.ga16...@nn.nn
Re: md5sums files
On Wed, Mar 03, 2010 at 05:41:26PM -0600, Peter Samuelson wrote: [Harald Braumann] Given a .deb, turning the data.tar.gz into foo.md5sums is a SMOP. This could be before, during, or after the deb is unpacked. If you create the hashes at unpack time, you don't catch errors that happen during unpack. You mean errors reading the data.tar.gz file? That is what the gzip checksum is for, as I said later in my email. Errors writing a file. If there should be support in the future for signing hash files, then creating them would have to be done at package creation time anyway. Also, I think, that it is in general better to have as much complexity as possible in the package builder and make the client tools as dumb as possible. harry -- 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/20100304002053.gb16...@nn.nn
Re: md5sums files
On Wed, Mar 03, 2010 at 06:50:28PM -0600, Peter Samuelson wrote: [Harald Braumann] On Wed, Mar 03, 2010 at 05:41:26PM -0600, Peter Samuelson wrote: [Harald Braumann] Given a .deb, turning the data.tar.gz into foo.md5sums is a SMOP. This could be before, during, or after the deb is unpacked. If you create the hashes at unpack time, you don't catch errors that happen during unpack. You mean errors reading the data.tar.gz file? That is what the gzip checksum is for, as I said later in my email. Errors writing a file. Did you read the text you quoted? Given a .deb, turning the data.tar.gz into foo.md5sums is a SMOP. (By SMOP, I meant simple matter of programming.) This has nothing to do with writing a file, except writing /var/lib/dpkg/info/foo.md5sums, which is unavoidable. I think I was finally able to decipher your message. But my other points still hold. And while it is just a matter of programming, simple or not, it already exists in debhelper. So doing it at build time is SMOAOLTDR, by which I mean simply a matter of adding one line to debian/rules. harry -- 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/20100304011155.gd16...@nn.nn
Re: GDM, getty and VTs
On Sat, 14 Nov 2009 15:45:11 +0100 Josselin Mouette j...@debian.org wrote: Hi, it’s been a long-standing tradition on Linux to have 6 started getty processes, in tty1 to tty6. However this doesn’t correspond anymore to the way we use our machines. * I don’t think we need more than 2 of these. They are still useful for servers or when some disaster happens in the GUI, but who opens 6 console sessions nowadays? I do. And if people don't use them, there's still no harm done. * For desktop machines, the display manager starts on tty7, which means there is a tty switch to display it. This causes a small latency I think the latency comes from the switch from text mode to graphical mode, which should be alleviated by KMS. and can also create some bugs when you’re using a graphical boot splash. Which bugs? To make things worse, the latest GDM upstream version doesn’t include a tty manager anymore. Each started X server will simply use the first available VT. Red Hat can afford to do that because their gdm is started by the inittab (which is really a bad idea, but well), but in Debian this means it takes tty1, stomping on the getty that gets launched here later. So before we start adding hacks on top of the existing, maybe now is the time to think about how we want to use our VTs. 1/ What should be on tty1? Ideally, we should have the display manager here if it is started, Why? 2/ How do we prevent bad interaction between console VTs and graphical VTs? (Of course this is closely related to question 1.) Given how they are done now, there will always be some race conditions in VT allocations without a tty manager. But as long as this code stays in GDM (and KDM, for that matter), we will be stuck to static allocation of pools of VTs prior to start anything. What's the actual problem with that? We can do better than that, but this requires system-wide allocation of VTs that could be queried from the display manager. What's the use-case for that? I don't see any real arguments against the set-up as it is now or for a new way to do it. Just because GDM is broken doesn't mean we should change a system that is, in your own words, a long-standing tradition. I see no gain at all in that but instead it seems it would make the system more complex, harder to understand and confuse users. Cheers, harry signature.asc Description: PGP signature
Re: GDM, getty and VTs
On Mon, 16 Nov 2009 11:07:52 +0100 Josselin Mouette j...@debian.org wrote: Le lundi 16 novembre 2009 à 10:33 +0100, Harald Braumann a écrit : I don't see any real arguments against the set-up as it is now or for a new way to do it. There are no real arguments for keeping the current setup either. Yes there is: that it has been like this forever. This is a value of its own, because users expect it to be like this and rely on it. Changing it will confuse many. It doesn't mean that it is carved in stone, but there should be good reasons and the gain should outweigh the cost. Just because GDM is broken doesn't mean we should change a system that is, in your own words, a long-standing tradition. Just because it is a tradition doesn’t mean it’s the correct way. So far I haven't seen any argument as to why it shouldn't be the correct way. Actually, several people in this thread felt the current way is better, while explaining they don’t have *enough* text VTs for their personal use in the default setup. Let me sum up the situation otherwise: * Current situation is far from perfect. Why? * New GDM upstream, as is, is completely broken. That seems to be the only reason. But this is clearly a bug in GDM, that should be fixed there. Let me explain what proposal I have in mind after reading the thread, now. It might sound a little crazy but I think it would be much better than just keeping our current setup. We remove entirely the getty respawning from /etc/inittab. Instead, a new daemon is started by a regular init script. This daemon does the following: * Opens all /dev/tty1 to tty6 and display a d-i-like “press enter to activate this console” in them. * Provide a very simple interface to reserve a VT, that can be queried by the display manager. * Whenever you press enter on a VT, reserve it and start a getty process. * When almost all ttys are allocated, start opening tty7+ and so on. * If no display manager is started, always run a getty process in tty1. To me, this seems like a solution looking for a problem. What use-case do you have in mind here? On my system it currently works like this: - start gettys in /etc/inittab - define X's tty in /etc/X11/xdm/Xservers If you want X on another tty, change it in /etc/X11/xdm/Xservers. If you need more ttys, add gettys to /etc/inittab. This system is so simple and flexible, that I don't see how you can improve on it. So the solution is to make GDM configurable by a parameter or a config file to set the vt it should start on. I don’t see this as rocket science software, and it means: * No useless getty processes are started. I never considered this to be a real problem. * tty1 is always the first VT you log on, regardless of your setup. I don't see this as an improvement. I always want X on the same tty, no matter in which order I do things. Or did I misunderstand something here? * You can start an arbitrary number of text or graphical consoles, without any configuration. Is this really a requirement? Where are the wishlist bugs of users demanding this? And anyway, a simple script that looks for the next free tty and spawns getty there solves this nice and easy. Cheers, harry signature.asc Description: PGP signature
Re: GDM, getty and VTs
On Mon, 16 Nov 2009 14:39:06 +0100 Josselin Mouette j...@debian.org wrote: Le lundi 16 novembre 2009 à 13:55 +0100, Harald Braumann a écrit : Just because it is a tradition doesn’t mean it’s the correct way. So far I haven't seen any argument as to why it shouldn't be the correct way. It’s broken because: * there are race conditions in the way VTs are allocated; Not if they're allocated statically. * text consoles are statically allocated, which means there are too many for some users and not enough for some others; That's easily configurable. * the display manager should run on the first VT. You keep suggesting this, but I don't agree. * New GDM upstream, as is, is completely broken. That seems to be the only reason. But this is clearly a bug in GDM, that should be fixed there. Yes, but there are better ways to fix bugs than mimicking already existing bugs. If you want X on another tty, change it in /etc/X11/xdm/Xservers. If you need more ttys, add gettys to /etc/inittab. This system is so simple and flexible, that I don't see how you can improve on it. Yeah, sure. Like, you know, dynamic VT allocation and X server. So the solution is to make GDM configurable by a parameter or a config file to set the vt it should start on. You really don’t know what you are talking about, do you? Well, maybe not, but that's because so far I haven't had nor heard of any problems with the current system and you refuse to explain what the real problem is. But I start to suspect that it might have to do with multiple X servers being started dynamically. If that's the case, and it does make problems, than that might very well be a reason that's more important than tradition (though I would prefer a solution that conserves tradition). I don’t see this as rocket science software, and it means: * No useless getty processes are started. I never considered this to be a real problem. I always consider it a problem when there are unneeded processes on the system. I consider a tty-management-daemon an unneeded process * tty1 is always the first VT you log on, regardless of your setup. I don't see this as an improvement. I always want X on the same tty, no matter in which order I do things. Or did I misunderstand something here? X is not always on the same tty. It is only if you use an antiquity like xdm. Even with startx, tty allocation is dynamic. Thanks to that antiquity, I will be able also in the future to have X on vt7. And I don't have to run gconf (speaking of unneeded processes). * You can start an arbitrary number of text or graphical consoles, without any configuration. Is this really a requirement? Where are the wishlist bugs of users demanding this? And anyway, a simple script that looks for the next free tty and spawns getty there solves this nice and easy. No it does not. Especially since “looking for the next free tty” is not a safe operation. Fair enough. It's just that I never felt the urge to allocate vts dynamically. Cheers, harry signature.asc Description: PGP signature
Re: Explicitely Cc bug reporters
On Fri, 11 Sep 2009 10:21:07 +0200 Frans Pop elen...@planet.nl wrote: Paul Wise wrote: I personally prefer not to be CCed on bug reports. I don't want to recieve any mail about a bug unless it is asking me to supply more information. So you *do* want to be CCed if the maintainer needs more information. Then there's one thing I don't get. - if we change the default to always CC, nobody is going to explicitly CC submitters anymore; that's only logical, correct? - you choose not to subscribe - ergo, you will never see any requests for additional information How would you solve that problem within your proposal? I see auto-subscribe as mainly a convenience for the submitter. It won't solve the problem you mention. If the maintainer has a question specifically to the submitter, he will have to cc him. I don't see any other solution. As I've mentioned before, IMO there is only one valid reason to unsubscribe from BRs after we change the default, and that is if you *already* receive follow-ups because - the package has Maintainer set to a mailing list and you are subscribed to that list - you are subscribed to bug mails for the package through the PTS Well, others might have their own reasons. I'm sorry that you consider receiving follow-ups an inconvenience, but IMO the benefit of in general being sure submitters will get follow-ups outweighs that. While I personally like to be kept updated on all bugs I file and would welcome an auto-subscribe feature, one has to accept the fact that others might not. I always find it very irritating if The System forces things on me because it thinks it knows what's best for everyone and regards me as a half-witted imbecile who is not capable of making his own decisions or anticipate their consequences. Therefore there needs to be an opt-out feature. And it should be clear how to opt out and simple to use. It will also solve the problem that I've seen numerous times that CCs from me directly get rejected by submitters through overly aggressive spam filtering. (And yes, I do send out mails through my ISP.) No it won't. If there is no simple way to opt-out, the spam filter is the only solution to work-around what some might consider an inconvenience. Cheers, harry signature.asc Description: PGP signature
Re: Registry for cache directories (to save backup space)
On Sat, 22 Aug 2009 22:43:11 +0800 Paul Wise p...@debian.org wrote: On Sat, Aug 22, 2009 at 10:23 PM, Thomas Kochtho...@koch.ro wrote: while watching rsnapshot doing a backup of my laptop, I thought: Wouldn't it be fine, to have a registry of cache directories that shouldn't be backed up? ... So a debian package could register all the places, where it puts caches and a system administrator could use this registry to speed up backups and save bandwidth and storage. Debian is the wrong place to do that, the FreeDesktop group and upstreams is the best place to do that. FreeDesktop is equally wrong, as not all applications are desktop applications (a point that is often forgotten, nowadays). The right place would be the FHS. Looks like there was discussion about this as far back as 2004: http://lists.freedesktop.org/archives/xdg/2004-July/thread.html#2603 http://www.brynosaurus.com/cachedir/ Probably just fixing all apps to use the XDG Base Directory spec and not backing up ~/.cache is enough though: I'm quite sure that not everyone would call that `fixing'. http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html http://packages.debian.org/sid/libxdg-basedir-dev Cheers, harry signature.asc Description: PGP signature
Re: default character encoding for everything in debian
On Wed, 12 Aug 2009 13:03:30 +0100 Roger Leigh rle...@codelibre.net wrote: On Wed, Aug 12, 2009 at 01:18:12PM +0200, Thomas Koch wrote: I'm not sure, whether a conclusion is already reached. 1. apt-get install mysql 2. enter mysql client 3. create database test; create table test( test char(10) ); Replace mysql with whatever application you like. What should be the encoding of database and table test in cases like the above? Currently it's iso-something, discriminating everybody from other countries. If it would be utf-8 instead, it would have at least two advantages - The clueless user would get a sane default - utf-8 isn't as discriminating as iso-8859-1 UTF-8 is the sane default choice in this situation, so long as MySQL is capable of handling it. Is that a real problem? Usually applications that use a SQL DB come with some script to set up the schema. If they want UTF-8, they will create a table with UTF-8 encoding. I wouldn't change MySQL's default without reason, because old scripts might rely on that behaviour. Those applications, however, should be configured to use UTF-8 by default (if they support it) and their DB setup scripts accordingly. Cheers, harry signature.asc Description: PGP signature
Re: default character encoding for everything in debian
On Thu, 13 Aug 2009 02:03:43 +0100 Roger Leigh rle...@codelibre.net wrote: On Wed, Aug 12, 2009 at 11:44:36PM +0200, Harald Braumann wrote: On Wed, 12 Aug 2009 13:03:30 +0100 Roger Leigh rle...@codelibre.net wrote: On Wed, Aug 12, 2009 at 01:18:12PM +0200, Thomas Koch wrote: I'm not sure, whether a conclusion is already reached. 1. apt-get install mysql 2. enter mysql client 3. create database test; create table test( test char(10) ); Replace mysql with whatever application you like. What should be the encoding of database and table test in cases like the above? Currently it's iso-something, discriminating everybody from other countries. If it would be utf-8 instead, it would have at least two advantages - The clueless user would get a sane default - utf-8 isn't as discriminating as iso-8859-1 UTF-8 is the sane default choice in this situation, so long as MySQL is capable of handling it. Is that a real problem? Usually applications that use a SQL DB come with some script to set up the schema. If they want UTF-8, they will create a table with UTF-8 encoding. I wouldn't change MySQL's default without reason, because old scripts might rely on that behaviour. Those old scripts which don't specify an encoding *are already buggy* due to not saying what they want, implying that the default (whatever that might be) is fine. Agreed. Still no need to break them on purpose. There's the possibility that this might cause some problems, but they are problems in the script, not in MySQL. Keeping using an obsolete encoding like Latin 1 (or whatever the default currently is) prevents any breakage, but at the expense of moving to a sane default for the future. I really don't care too much about the specific case of MySQL, as I hardly ever create or manipulate SQL data by hand. All I was saying and you seem to be saying as well, if I understand you correctly, is that it is the duty of the application that creates and uses SQL tables to specify the encoding, if it cares about it. If the application does that, it will work, no matter what default is specified for MySQL. So this specific case is a non-issue, IMO, and MySQL's default doesn't need to be changed. But if it is, just for the sake of it, then that's fine with me. Some scripts might break, but OK. Those applications, however, should be configured to use UTF-8 by default (if they support it) and their DB setup scripts accordingly. They should indeed, but if they don't then they need to explicitly spell out what they *do* support. The should. Cheers, harry signature.asc Description: PGP signature
Re: default character encoding for everything in debian
On Tue, 11 Aug 2009 13:28:08 -0500 Gunnar Wolf gw...@gwolf.org wrote: Harald Braumann dijo [Tue, Aug 11, 2009 at 01:33:58AM +0200]: There are a lot of users out there that are not willing to pay the price for increased generality. Don't you mean s/users/programmers? As a user I don't see what price I pay. I only see advantages in having a consistent encoding. Which, btw., doesn't have to be UTF-8. In an ideal world every programme would adhere to LC_CTYPE. But if the encoding has to be configured then I would also prefer UTF-8 as the default. Of course, for the programmer there might be a price to pay. And if he's not willing to pay it, he can't be forced, anyway. Or do you mean the user pays the price, because if the encoding is set to UTF-8 then performance would suffer? In that case, I'd love to see some real life numbers. I doubt the difference would be noticeable. Yes, performance will suffer. We enjoyed many decades of blissfully ignoring the difference between a character and a byte. Well, a byte with the most significant bit always set to 0. So, while length(str) in any language up to the 1990s was a mere substraction, now we must go through the string checking each byte to see if it is a Unicode marker and substract the appropriate number of bytes. Also, for a very long time we didn't really care much what was a buffer's content - And in these glorious times more often than not unintelligible rubbish was produced if you happened to not use a language that can be written in ASCII. But this is besides the point. I do appreciate that support for different character encodings causes pain for the programmer. But the original post was about software that already has got support for UTF-8 and whether it wouldn't be good idea to configure it this way by default. Everything could be printed, even if it had control characters which made you beep (with the ocassional control sequence re-injecting output into the terminal as input). Now... Well, printing an unprintable string can cause segfaults in some cases. My terminal supports UTF-8. I thought that this is not an issue any more. Cheers, harry signature.asc Description: PGP signature
Re: default character encoding for everything in debian
On Mon, 10 Aug 2009 13:45:40 +0200 Siggy Brentrup deb...@psycho.i21k.de wrote: On Mon, Aug 10, 2009 at 13:09 +0200, Thomas Koch wrote: Hi, I've an issue, that I forgot to set the character encoding of tomcat to utf-8 after reinstalling a server. Now, before I report a wishlist(?) bug to tomcat, I want to ask (and invite to discuss) shouldn't utf8 be the default character set everywhere? So when installing a package from Debian I can assume that where a character encoding can be set, it't set to utf8. MySQL would be another example, which to my knowledge uses isoXYZ as default character encoding. While utf-8 covers the broadest set of character glyphs possible, it suffers from size as well as performance penalties. Characters no longer are guaranteed to fit in a byte, how do you define strlen(utf8_string) c pp. All these issues have been solved but not for free. There are a lot of users out there that are not willing to pay the price for increased generality. Don't you mean s/users/programmers? As a user I don't see what price I pay. I only see advantages in having a consistent encoding. Which, btw., doesn't have to be UTF-8. In an ideal world every programme would adhere to LC_CTYPE. But if the encoding has to be configured then I would also prefer UTF-8 as the default. Of course, for the programmer there might be a price to pay. And if he's not willing to pay it, he can't be forced, anyway. Or do you mean the user pays the price, because if the encoding is set to UTF-8 then performance would suffer? In that case, I'd love to see some real life numbers. I doubt the difference would be noticeable. Cheers, harry signature.asc Description: PGP signature
Re: How to get all dependent source packages
On Tue, 21 Jul 2009 01:42:44 +0800 sha liu sandyle...@gmail.com wrote: 2009/7/20 Goswin von Brederlow goswin-...@web.de sha liu sandyle...@gmail.com writes: Hi everyone, Is there any easy method to get all the *source* packages which are the build dependency of one package? What I want to do is building dpkg from source on a CLFS[0] system. So I have to get all the dpkg's dependency source packages and the dependency of dependency and so on... I look into auto-apt, apt-get builddep. Both of them install the binary packages to fulfill the dependency, not downloading the source packages. It's crazy to download all dependent source packages of dpkg, right? Any suggestion is welcomed! [0][[http://trac.cross-lfs.org/]] For those don't know clfs, just think a CLFS system as a minimal linux system without debianization. -- Best, Sha Liu It is crazy. Or at least in general you can not build a source package without having a full build chroot with binaries already. Just the sources for a minimla build chroot are 800MB already and, last I checked, which is a few years back, include latex and X. Adding all the sources for the Build-Depends of those probably doubles the size again. Just build (c)debootstrap manually or use the static one and create a build chroot from debs. Hi Goswin. debootstrap will just install the binaries. However, what I want is building binaries on my own. The reason I want to do this is I want to port Debian to different arch(MIPS III and loongson 2F), considering there're only mips and mipsel port in Debian archive now. Use pbuilder. It creates a chroot, downloads and installs all required packages and then builds your source package. Btw., the base chroot is about 80MB (gzipped). How big it gets when building depends on the dependencies, but I never had to download 800MB (if I understood correctly, you don't want to build the whole distribution, just a single package, rigth?) Cheers, harry -- Best, Sha Liu MfG Goswin signature.asc Description: PGP signature
Re: Switching the default /bin/sh to dash
Hi, On Wed, 24 Jun 2009 17:51:58 -0500 Raphael Geissert atom...@gmail.com wrote: Hello everybody, I think everyone readying this list is more than aware of the intention to switch to dash as the default /bin/sh. A lot of work has been done on many sides to make this switch doable and as smooth as possible and plenty of people has been contributing by testing, filing bugs, providing patches, fixing bugs and by using dash. [...] * and performing another archive-wide checkbashisms check on binary Checkbashisms is a lintian check, right? Can I use it to check my own scripts, not being in a package? Cheers, harry signature.asc Description: PGP signature
Re: Bug#531221: okular: Arbitrarily enforces DRM
On Sun, 31 May 2009 14:19:12 +0200 Michael Banck mba...@debian.org wrote: I like the advisory note somebody else proposed, i.e. The author said you shouldn't do this, do you want to do this anyway?. Whether or not that dialog could get permanently ignored by the user could be configurable. I can't think of many dialogs that would be more useless than asking the user if he wants the software to forbid him to do what he asks it to do. Cheers, harry signature.asc Description: PGP signature
Re: Bug#531221: okular: Arbitrarily enforces DRM
On Tue, 02 Jun 2009 06:59:03 -0300 David Bremner brem...@unb.ca wrote: Harald Braumann wrote: [1 text/plain; US-ASCII (quoted-printable)] On Sun, 31 May 2009 14:19:12 +0200 Michael Banck mba...@debian.org wrote: I like the advisory note somebody else proposed, i.e. The author said you shouldn't do this, do you want to do this anyway?. Whether or not that dialog could get permanently ignored by the user could be configurable. I can't think of many dialogs that would be more useless than asking the user if he wants the software to forbid him to do what he asks it to do. Like the following, you mean? No, of course not. dulcinea:~/tmp % rm * zsh: sure you want to delete all the files in /home/bremner/tmp [yn]? harry signature.asc Description: PGP signature
Re: deprecating /usr as a standalone filesystem?
On Tue, 5 May 2009 17:36:02 +0200 m...@linux.it (Marco d'Itri) wrote: I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. So, does anybody still see reasons to continue supporting a standalone /usr? If you do, please provide a detailed real-world use case. A partial list of invalid reasons is: - I heard that this was popular in 1998 - it's a longstanding tradition to support this - it's really useful on my 386 SX with a 40 MB hard disk This thread has been going on for quite some time without any insight into what the actual problem with a separate /usr might be. Could you please elaborate? The only issues I can think of are hard links and atomic renames. Though I can't think of any use-case where you would need this between /usr and some place outside /usr. Cheers, harry signature.asc Description: PGP signature
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
On Thu, 07 May 2009 08:01:11 +0200 Giacomo Catenazzi c...@debian.org wrote: Luk Claes wrote: Steve Langasek wrote: On Tue, May 05, 2009 at 05:06:26PM +0200, martin f krafft wrote: also sprach Carsten Hey cars...@debian.org [2009.05.05.1645 +0200]: FWIW, Ubuntu did what I consider the right thing: http://launchpadlibrarian.net/21235281/mdadm_2.6.7.1-1ubuntu4_2.6.7.1-1ubuntu5.diff.gz Well, this is the right thing in Ubuntu because postfix is the default MTA for Ubuntu. In Debian, this is not the case, so mdadm recommending postfix by preference causes inconsistent behavior depending on the order in which the user installs packages. Maybe we should also consider changing the default MTA to postfix? No, most of users don't need a full MTA, but only a local MTA (usually only sendmail command, but ev. only a socket listening to localhost:25). SO I would propose a more simple mailer (esmtpd, nullmailer, ...) No, please don't use an esoteric mailer. People who don't know and don't want to know about their local mailer don't need to know about Postfix' complexity. They can set up Postfix with a single debconf questions to a minimal configuration. And people who have to administrate multiple servers will have the same mailer on all of them, even if only some are real MTAs and the others just need to send mail. I was so looking forward to the day when the first step after installing Debian wouldn't be to replace the default MTA with Postfix... Cheers, harry signature.asc Description: PGP signature
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
On Thu, 07 May 2009 13:28:33 +0200 Josselin Mouette j...@debian.org wrote: Le jeudi 07 mai 2009 à 13:23 +0200, Harald Braumann a écrit : No, please don't use an esoteric mailer. People who don't know and don't want to know about their local mailer don't need to know about Postfix' complexity. They can set up Postfix with a single debconf questions to a minimal configuration. How is that an improvement over Exim? I never talked about Exim. I was just opposing the proposition, that some esoteric mailer like nullsmtp or esmtp will become the default in Debian. Cheers, harry signature.asc Description: PGP signature
Re: Considering the removal of ntpdate
On Thu, 23 Apr 2009 18:19:07 +0200 Stefan Ott ste...@ott.net wrote: On Thu, Apr 23, 2009 at 17:45, Peter Eisentraut pet...@debian.org wrote: Nevertheless, since ntpdate used to be quite popular, I figured I'd better ask here for objections. I still use it when a system's clock is way off and I just want it to be set to the right time, right now. I guess there are options to ntpd to do that, so maybe a little wrapper script (telling the user about the appropriate ntpd command, similar to 822-date) might be a nice idea. It's `ntpd -q'. Possibly you'll also need option `-g'. harry signature.asc Description: PGP signature
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Sun, 12 Apr 2009 15:15:56 +0200 Raphael Hertzog hert...@debian.org wrote: That said, it looks like that having things just work on the desktop require hal anyway and I fail to see why we would have to reinvent other solutions (like continuing to maintain/create many hacks in acpi-support) when we could centralize the knowledge in one place. What's the connection between ACPI and The Desktop? Could you outline the use-case HAL satisfies with regard to ACPI? Cheers, harry signature.asc Description: PGP signature
Re: Google Summer of Code 2009: Debian's Shortlist
=== Debian's Shortlist: === = - Aptitude Package Management History Tracking /var/log/dpkg.log? harry signature.asc Description: PGP signature
Re: lilo about to be dropped?
On Mon, 06 Apr 2009 10:24:54 -0500
William Pitcock neno...@sacredspiral.co.uk wrote:
On Mon, 2009-04-06 at 16:17 +0200, Harald Braumann wrote:
Yes, I do and it works without problems. There are some
inconveniences, though, with grub2, which might make some stick
with LILO:
The LVM support in LILO is hideously broken, so these arguments do not
really matter.
Works for me.
It only works in certain conditions and is known to
break horribly if you have say, a kernel spanning multiple PVs.
Only a true idiot boots off an LVM volume anyway,
You're too nice. Anyway, boot is the least important partition. Any
live CD or USB installation will do to recover.
since there is risk of metadata corruption, etc.
What metadata are you talking about, and what's it got to do with the
boot partition?
The is no simple configuration file that one could edit. You have to
write scripts to add entries.
/boot/grub/{menu.lst,grub.conf} is hard to edit...?
No, but since grub2 doesn't use those, your statement is moot. So are
the following.
You can't specify the default entry (only the number of the entry,
which changes if a new kernel is installed) and there is no
vmlinuz/vmlinuz.old (unless you add a script that adds these
entries)
default X in the config file, and setdefault, works for me.
You can't specify boot options per entry (there's only a global
option in /etc/default grub, that applies to all entries).
Sure you can, just don't use update-grub(1) and update it yourself
instead. Same as lilo, really.
William
harry
signature.asc
Description: PGP signature
Re: lilo about to be dropped?
On Mon, 6 Apr 2009 17:03:10 +0800 Paul Wise p...@debian.org wrote: On Mon, Apr 6, 2009 at 4:49 PM, Romain Beauxis wrote: I also use lilo for /boot on LVM and I also clearly remember that was the major reason for the previous debate about the removal of lilo. Grub2 in lenny and later contains an lvm module: /usr/lib/grub/i386-pc/lvm.mod Has anyone who uses lilo for this tried grub2? Yes, I do and it works without problems. There are some inconveniences, though, with grub2, which might make some stick with LILO: * on boot it takes quite some time for grub2 to scan the disks for LVM volumes * configuration of grub2 is really a PITA The is no simple configuration file that one could edit. You have to write scripts to add entries. You can't specify the default entry (only the number of the entry, which changes if a new kernel is installed) and there is no vmlinuz/vmlinuz.old (unless you add a script that adds these entries) You can't specify boot options per entry (there's only a global option in /etc/default grub, that applies to all entries). Cheers, harry signature.asc Description: PGP signature
Re: Transition of initscripts to new order / sequence number
On Mon, 23 Mar 2009 09:51:09 -0300 Henrique de Moraes Holschuh h...@debian.org wrote: Only, in this case, we need it abstracted (which it already is), and we need it to _remain_ abstracted. Otherwise, we will have massive pains to switch initsystems (as in: it will be either completely impossible, or it will take two or three stable releases to do it). It was trouble enough to implement invoke-rc.d. Who would want to do that, anyway? Why replace a simple working solution with something complex and overengineered? It's getting harder and harder to really understand the system because so many things get replaced by more complex solutions and basic interfaces are abstracted and thus become inscrutable. Cheers, harry signature.asc Description: PGP signature
Re: Proposal to improve package configuration upgrades
On Fri, 27 Feb 2009 13:35:56 +0100 Dominique Dumont dominique.dum...@hp.com wrote: Stefano Zacchiroli z...@debian.org writes: But then we are back at the issue of a 80-20 problem, and I see the VCS solution as more flexible and more readily available. Agreed. But VCS solution is a 80% success/20% silent failure. Config::Model is a 80% success/20% abort. The latter should be easier to deal with for average user. But you don't need to silently merge (and thus silently fail in some cases). You can still ask the user about confirmation. harry signature.asc Description: PGP signature
Re: Proposal to improve package configuration upgrades
On Wed, 25 Feb 2009 17:32:08 +0100 Dominique Dumont dominique.dum...@hp.com wrote: Harald Braumann ha...@unheit.net writes: I don't really know Config::Model. But the main problem I have with the current system is, that I only see diffs between the currently installed version and the new package version. With ucf, you see a diff between current file (i.e. installed version with your modifications) and the new package version. That I also see without ucf. No what I really would like to see is the diff between the last version I've merged and the new package version. I fail to see the differences (no pun intented) between the last version I've merged and the current file ... I mean the last maintainer version I merged into the installed version, not the result of the last merge. So changes can easily be seen (changes in defaults, new/removed parameters or just white-space changes?) and merging would work without a conflict in most cases. With Config::Model: - you would not see white space or any other formatting difference - your customized values would be merged into the new package file (more accurately, loaded in Config::Model configuration tree using the new package *model*). Thus you would see the delta between your new file and the new default value. See this example of a screenshot [1] where the config values different from default are shown with a green arrow But there are 3 possible situations here: 1. value has been changed between the last and the new maintainer version 2. value was modified locally 3. both of the above In case 1 the modification could be merged silently, in case 2 the modification should be left alone and in case 3 I'd have to decide what to do. Config::Model on its own couldn't tell the difference. - yes, merging would work mostly without conflict Similar to like SCMs work. The main difference between a SCM and Config::Model is that a SCM works purely at text level without knowledge of the semantic of the file under control. OTOH, Config::Model uses the semantic knowledge provided by the model to perform the upgrade. You could apply the way merges work in an SCM to structured information. Config::Model could be useful in addition, but would it support such a work-flow? Provided I've understood correctly your work-flow, I'd say mostly yes... Having the diff between the last and the new maintainer version is not an alternative to Config::Model. The former can tell me what has changed in what way and the latter can present this information enriched with its semantic knowledge of the changes. Both are things I find useful. So my question is, if Config::Model can also deal with the additional information of what has changed how, so the two things could be combined? Cheers, harry signature.asc Description: PGP signature
Re: Proposal to improve package configuration upgrades
On Wed, 25 Feb 2009 12:08:00 -0600 Manoj Srivastava sriva...@debian.org wrote: Well. If the maintainer so desires, ucf does have this to say: ,[ Manual page ucf(1) ] | --three-way I thought I remembered seeing smth. like this. Seems like this is what is desired; Yes, this is exactly what is desired. however, the reason this is not on by default is that some configuration files can be huge, and ucf did not want to stash away _all_ the configuration files handled by it into /var. The exectation was that most developers with smallish configuration files would use --three-way, but that expectation was unfounded. Could this be made configurable locally? So the maintainer could still set whatever default he finds useful but it could be overridden by the admin? So everyone is happy. Cheers, harry signature.asc Description: PGP signature
Re: Accelerated video cards and non-free firmware
On Wed, 25 Feb 2009 16:28:39 -0500 Daniel Dickinson csh...@bmts.com wrote: Hi, I'm looking at getting a video card, and I want to know what video card that has 3D acceleration to get. Normally I'd ask on -users but as the subject says I want to know what video cards will still have acceleration when the non-free firmware is removed from the kernel, which is supposed to happen for squeeze. I had heard that the ATI cards, which would normally be my first choice, have non-free firmware in the driver, which may be removed. Is this true, and if so what accelerated cards will have have acceleration once non-free firmware is removed. Development of open source drivers is moving quite fast these days. So I would expect decent 3D acceleration in open source drivers at the time Squeeze is release. Best to ask on x...@lists.freedesktop.org. Cheers, harry signature.asc Description: PGP signature
Re: Security Issue of .desktop files
On Tue, 24 Feb 2009 23:36:38 + Matthew Johnson mj...@debian.org wrote: On Tue Feb 24 23:44, Yves-Alexis Perez wrote: On mar, 2009-02-24 at 17:33 -0500, Michael S. Gilbert wrote: here is a .desktop file that looks like it is iceweasel, but really it downloads an essentially random file, but I could have made it do pretty much anything. Yes, tests may need to be narrowed. That should be part of the spec, though. Speaking as someone with a PhD in computer security (and my PhD was in this area) I can tell you that trying to use heuristics in order to determine if something is 'bad' does not, and it's fairly widely recognised cannot, work. Not only widely recognised, it's proven. People with or without a PhD might look up the halting problem. I firmly agree with Michael that the only good solution is to require explicit marking or .desktop files in some fashion. Isn't downloading something, putting it on the desktop and clicking on it a strong enough indication of the user's will to execute whatever it is? If he does all this without blinking once, he surely wouldn't have any concerns about setting the x bit, if that gets him what he wants, i.e. to execute the file. As long as most people think, that embedded scripts, programmes opening all sorts of crap automatically and .dektop files are really a great idea, trouble won't be amiss, no matter how many warning pop-ups, checks or blocks you put in front. I fear the day, when I can download soft links and disguise shell scripts as pictures. Cheers, harry signature.asc Description: PGP signature
Re: Proposal to improve package configuration upgrades
On Wed, 25 Feb 2009 09:28:52 +0100 Dominique Dumont dominique.dum...@hp.com wrote: Of course, there's no miracle. For the merge to work automatically and the result to be valid, the semantic of the configuration file must be known by Config::Model. This is done by describing the structure and constraints of the configuration file in a model (hence the Config::Model name). What do you think about this ? I don't really know Config::Model. But the main problem I have with the current system is, that I only see diffs between the currently installed version and the new package version. No what I really would like to see is the diff between the last version I've merged and the new package version. So changes can easily be seen (changes in defaults, new/removed parameters or just white-space changes?) and merging would work without a conflict in most cases. Similar to like SCMs work. Config::Model could be useful in addition, but would it support such a work-flow? Cheers, harry signature.asc Description: PGP signature
Re: cgroup mount point
On Thu, 05 Feb 2009 22:19:37 +0100 José Luis Tallón jltal...@adv-solutions.net wrote: [...] whereas I can't fathom why a cgroup feels like a /device/. I admit not being an expert in virtualization abstraction (I do run a significant number of virtual machines, tough), but in fact /sys seems to be a much better place for it. Please feel free to argue against if my proposal does not in fact make sense. Agreed. Semantically /sys is probably the place for cgroups. While it does indeed feel hackish, mounting a tmpfs on /sys/cgroups and then creating as many subdirs as/if necessary is indeed achievable, practical and flexible. Yes, folks have brought forth this technical difficulty and that's why I initially thought /dev to be a better place. For me, either would be OK. I don't care that much as long as it's not mounted in root. /proc might be useable though, but it has historically been associated with processes and the information related to them. And yes, that means that /proc/cpuinfo, /proc/meminfo, and /proc/bus would actually be out of place there... but keeping backwards compatibility and not surprising users is most important. Agreed. I think the trend is to remove things not related to processes from /proc. Of course not everything can be removed immediately, but at least no new things should be added. Cheers, harry signature.asc Description: PGP signature
Re: cgroup mount point
On Tue, 3 Feb 2009 11:14:03 -0800 Paul Menage men...@google.com wrote: On Tue, Feb 3, 2009 at 10:51 AM, sean finney sean...@seanius.net wrote: or /proc/bus/usb or /dev/shm or /dev/pts... :) /dev is a bit different though - even if it's mounted as a udev fs, you can create a new directory in there to act as a mount point. So, what's the problem with /dev/cgroups then? If shm/ and pts/ are allowed under /dev, wouldn't it be discriminating against cgroups/, to not allow it there? Cheers, harry signature.asc Description: PGP signature
Re: cgroup mount point
On Tue, 3 Feb 2009 15:40:39 -0800 Paul Menage men...@google.com wrote: On Tue, Feb 3, 2009 at 3:38 PM, Harald Braumann ha...@unheit.net wrote: So, what's the problem with /dev/cgroups then? If shm/ and pts/ are allowed under /dev, wouldn't it be discriminating against cgroups/, to not allow it there? Right, that's what I proposed a couple of emails earlier in this thread. Sorry, I didn't mean to imply that you'd be against it, on the contrary, I took your explanation as another argument for using /dev and against /sys (/cgroups should not even be considered, IMHO). The question was targeted at those, who oppose it. Cheers, harry signature.asc Description: PGP signature
Re: Release Candidate 2 of Debian Installer
On Tue, 3 Feb 2009 12:35:48 +0900 Paul Wise p...@debian.org wrote: How about letting the person doing the installation write the labels if they want to use LABEL and use UUID by default. Or as a third option, put everything in LVM, including boot and root, and the problem goes away. GRUB2 would have to be used, though. Cheers, harry signature.asc Description: PGP signature
Re: Change user used by package
On Wed, 14 Jan 2009 13:49:22 -0500 Jamin W. Collins jcoll...@asgardsrealm.net wrote: Marvin Renich wrote: * Harald Braumann ha...@unheit.net [090113 05:47]: AFAIK, there's no way for multiple independent packages for using the same user. So jabber-muc needs to create its own user. On update, that's no problem. The post-install script can chown the package's directories for the new user. But a downgrade would then not be possible. The old version couldn't access the directories. Is there precedence for such a situation? How can it be resolved? Cheers, harry BTW, are you coordinating this with the current jabber-muc maintainer (CC'ed in case he is not subscribed)? Sorry, I should have coordinated this with Jamin from the beginning, but I needed the package quickly, so I built it my own. I'm not subscribed, haven't been following the lists for a while. The old package should probably be removed completely in favor of the new. I'll file a bug report with a pointer to my sources. There have been very recent changes in upstream's source repository (http://svn.gna.org/viewcvs/mu-conference/trunk/), so it seems it's not dead, after all. Jamin: are you still willing to maintain that package? I can help with packaging, but I'm not a DD myself. Cheers, harry signature.asc Description: PGP signature
Re: Change user used by package
On Wed, 14 Jan 2009 09:25:53 -0500 Marvin Renich m...@renich.org wrote: * Harald Braumann ha...@unheit.net [090113 16:49]: Well, jabber-common does remove the user jabber on purge, jabberd2, though, doesn't. And it seems that opinions diverge on this matter. See e.g. http://lists.debian.org/debian-mentors/2004/10/msg00338.html. I've filed a bug against jabber-common. Though the thread started without a consensus, it ended with a clear consensus that the user should not be removed. Thanks. I think I take the easy way out. I'll use the user jabber (create it, if it doesn't exist) and don't delete it. I'll also add a conflict to jabber-common. If that's a problem for someone, a more sophisticated solution can still be implemented. Why do you need to conflict with jabber-common? Both can use the same user, unless there is a security issue and you don't want executables from jabber-common to be able to read your config files, in which case you should use a different user anyway. Was there another reason independent of the user issue? jabber-muc needs to conflict with jabber-common, until there is a version that does not remove the user on purge. Otherwise, when both are installed and jabber-common is purged, jabber-muc stops working because the user jabber is remove. Cheers, harry signature.asc Description: PGP signature
Change user used by package
Hi, I'd like to package mu-conference 0.7 (multi-user chat component for jabber). The version currently in Debian (jabber-muc 0.6.0) uses the user ``jabber'', which is created by jabber-common, on which jabber-muc depends. The new version can be installed stand-alone, and thus there won't be any dependence on jabber anymore, or jabberd2, for that matter. AFAIK, there's no way for multiple independent packages for using the same user. So jabber-muc needs to create its own user. On update, that's no problem. The post-install script can chown the package's directories for the new user. But a downgrade would then not be possible. The old version couldn't access the directories. Is there precedence for such a situation? How can it be resolved? Cheers, harry signature.asc Description: PGP signature
Re: Change user used by package
On Tue, 13 Jan 2009 12:55:31 +0100 Rene Engelhard r...@debian.org wrote: Hi, Harald Braumann wrote: package's directories for the new user. But a downgrade would then not be possible. The old version couldn't access the directories. Is there precedence for such a situation? How can it be resolved? Downgrades are not supported. (which doesn't mean they should if it's sane to do so, in this case I don't see how) OK, thanks. I'll go that route then and ignore ``downgradabilty''. Cheers, harry signature.asc Description: PGP signature
Re: Change user used by package
On Tue, 13 Jan 2009 12:51:29 +0100 Francesco P. Lovergine fran...@debian.org wrote: On Tue, Jan 13, 2009 at 11:35:49AM +0100, Harald Braumann wrote: AFAIK, there's no way for multiple independent packages for using the same user. Why not? There are already multiple packages that use the same user, e.g. www-data. You should only create it and never remove to avoid breakages for other packages installed at the same time. www-data is a globally allocated user. It would of course be possible to switch to such a user, but that would need changes of base-passwd and all jabber-related packages. I'm not sure, if it's worth the trouble. I'm also not sure if a consensus would be reached about the necessity of a globally allocated jabber user in Debian. Especially as I don't see much chance of that package getting into Debian main, given that it's practically unmaintained by upstream. Cheers, harry signature.asc Description: PGP signature
Re: Change user used by package
On Tue, 13 Jan 2009 09:15:47 -0800 Russ Allbery r...@debian.org wrote: Harald Braumann ha...@unheit.net writes: Francesco P. Lovergine fran...@debian.org wrote: On Tue, Jan 13, 2009 at 11:35:49AM +0100, Harald Braumann wrote: AFAIK, there's no way for multiple independent packages for using the same user. Why not? There are already multiple packages that use the same user, e.g. www-data. You should only create it and never remove to avoid breakages for other packages installed at the same time. www-data is a globally allocated user. It would of course be possible to switch to such a user, but that would need changes of base-passwd and all jabber-related packages. Well, yes, but I don't see why you'd need a globally allocated user. Why don't you just use the same username as the other package? I don't see why that wouldn't work, and I don't see anything in Policy 9.2 that says you shouldn't do that. But it's not nice to let stuff lying around after a purge. Hm. I suppose that you'd get in trouble if either package removed the user on purge or renamed the user to something else without coordination. That's the problem. All the other package, that use the jabber user would have to be changed too, so as not to remove the user on purge. Additionally, jabber-muc would have to conflict with previous versions of those packages. I thinks its actually a bug, that jabberd2 doesn't have a conflict with jabber-common (both create/remove the user jabber, without dependency). I'll file a report. The other route, of creating a new user and not supporting a downgrade, seems much saner and more straightforward to me. Cheers, harry signature.asc Description: PGP signature
Re: Change user used by package
On Tue, 13 Jan 2009 12:57:11 -0800 Steve Langasek vor...@debian.org wrote: On Tue, Jan 13, 2009 at 09:49:17PM +0100, Harald Braumann wrote: Well, yes, but I don't see why you'd need a globally allocated user. Why don't you just use the same username as the other package? I don't see why that wouldn't work, and I don't see anything in Policy 9.2 that says you shouldn't do that. But it's not nice to let stuff lying around after a purge. You should never remove users and groups on purge. Not even if I created them in post-inst? Oh, I didn't know that. That makes the problem go away, of course. Cheer, harry signature.asc Description: PGP signature
Re: Change user used by package
On Tue, 13 Jan 2009 12:57:11 -0800 Steve Langasek vor...@debian.org wrote: On Tue, Jan 13, 2009 at 09:49:17PM +0100, Harald Braumann wrote: Well, yes, but I don't see why you'd need a globally allocated user. Why don't you just use the same username as the other package? I don't see why that wouldn't work, and I don't see anything in Policy 9.2 that says you shouldn't do that. But it's not nice to let stuff lying around after a purge. You should never remove users and groups on purge. That's the problem. All the other package, that use the jabber user would have to be changed too, so as not to remove the user on purge. If they remove the user on purge, that should be changed anyway. Well, jabber-common does remove the user jabber on purge, jabberd2, though, doesn't. And it seems that opinions diverge on this matter. See e.g. http://lists.debian.org/debian-mentors/2004/10/msg00338.html. I think I take the easy way out. I'll use the user jabber (create it, if it doesn't exist) and don't delete it. I'll also add a conflict to jabber-common. If that's a problem for someone, a more sophisticated solution can still be implemented. Cheers, harry signature.asc Description: PGP signature
Re: Josselin Mouette and Planet Debian
On Fri, 19 Dec 2008 01:04:05 +0100 Johannes Wiedersich jow...@googlemail.com wrote: Pierre Habouzit wrote: On Thu, Dec 18, 2008 at 10:28:09PM +, Russell Coker wrote: The creation of a fake picture of Manoj wearing leather makes it clear that Joss was intending to make an insinuation of homosexuality in order to offend. I'm really speechless... I mean, even from you I'm still not sure it's not a practical joke. I am really speechless The French seem to have a completely different understanding of the English language used in all these matters than almost every one else in the world. Well, the same expression exists in German, the stick just goes in the other end. Do you see any fellatial connotation there? Cheers, harry, who is quite puzzled by so much stiffness signature.asc Description: PGP signature
Re: Standard way to disable services
On Thu, 31 Jul 2008 10:56:07 -0400 Guido Günther [EMAIL PROTECTED] wrote: We might not want to use policy-rc.d as is in sysvinit of filerc during startup but we might consider moving these policy decisions no I don't want this daemon at startup, yes I want that daemon reloaded after resume into a policy layer that is independent of the underlying init mechanism and which can be queried by the different tools be it during system startup/shutdown or after/before suspend to/from ram/disk. Cheers, Is it really necessary? I'm not a big fan of abstraction layers. They usually complicate things instead of making them easier. So far for me the sysv init process with its start and kill links is sufficient for all purposes. It's a simple and stable system. Don't add complicated cruft on top of it. I never had the need to restart daemons on suspend/resume. But if this should be supported, then I'd prefer, if extra runlevels were defined for going into suspend (similar to rc0.d) and for resuming (similar to rcS.d) Cheers, harry signature.asc Description: PGP signature
Re: Standard way to disable services
On Wed, 30 Jul 2008 08:24:46 +0200 Marc Haber [EMAIL PROTECTED] wrote: On Sat, 26 Jul 2008 17:42:35 +0200, Nico Golde [EMAIL PROTECTED] wrote: There is also the option to install file-rc and just edit /etc/runlevel.conf with an editor if you don't want to cope with the symlink hell. That's how I have been doing things for years, but that's going to be incompatible with a future dependency-based init process. Which is something I really don't look forward too. Greetings Marc signature.asc Description: PGP signature
Re: Standard way to disable services
On Sun, 27 Jul 2008 15:21:44 +0800 Lightning [EMAIL PROTECTED] wrote: you should use the rcconf to disable the services apt-get install rcconf But that surely isn't the standard way, 'cause otherwise the package wouldn't be priority optional. Thanks for all the suggestions, I know that there are many ways to do it, and everyone has his preferences. But obviously there is not really a standard way in Debian. I have to take care of quite a view Debian hosts together with others. Sometimes people involved also change and new folks have to take over from previous ones. If multiple people are working on the same systems, it's good if everyone does things the same way everywhere. So usually I try to stick as close as possible to the way intended in Debian. That minimises overhead of communication and documentation. Unfortunately, it seems that there is no best practise for enabling/disabling services. The Debian Reference manual currently states in chapter 2.4.3, that the way to go is by manipulating runlevels. But this is really cumbersome, no runlevel editor is installed by default and the manual then goes on to explain all the problems with that approach, which would suggest that the exit 0 or chmod a-x approaches are far superior when you want to completely disable a service. Cheers, harry 在 2008-07-26六的 13:18 +0200，Harald Braumann写道： Hi, quite often I just want to disable a service in /etc/init.d. But there doesn't seem to be a standard way to do that. Many services have a file in /etc/defaults, where the service can be disabled. In that case, however, the service also can't be started manually. In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+462155 I was told to use sysv-rc-conf. I didn't know that tool before. But it seems a reasonable option. I usually end up removing the execute bit, as this is the simplest solution and the service can still be started manually. Shouldn't there be some default way in Debian to disable services? post-install scripts, which ask whether the service should be enabled should adhere to it and it should be supported by tools and also mentioned in the manual. sysv-rc-conf would be one option, in which case it would have to have priority required. The other option being removing the executable bit. I would be content with either, but I think it would be a good idea to agree on a standard. Cheers, harry signature.asc Description: PGP signature
Re: Standard way to disable services
On Sat, 26 Jul 2008 19:27:27 +0200 Luk Claes [EMAIL PROTECTED] wrote: Steve Langasek wrote: On Sat, Jul 26, 2008 at 02:11:26PM +0200, Josselin Mouette wrote: Le samedi 26 juillet 2008 à 13:18 +0200, Harald Braumann a écrit : quite often I just want to disable a service in /etc/init.d. But there doesn't seem to be a standard way to do that. The standard way is to remove the symlinks in /etc/rc?.d No, the standard way is to *rename* the S symlinks to K symlinks. One draw back is that it's not obvious what used to be an S link if you want to reenable them, that's why I rename them to s symlinks... That's what sysv-rc-conf takes care of. It saves information about the original symlinks, so you can restore them later. harry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
On Tue, 26 Feb 2008 14:45:05 +0100 Miriam Ruiz [EMAIL PROTECTED] wrote: 2008/2/26, David Given [EMAIL PROTECTED]: Lars Wirzenius wrote: I'd really rather see something nicer than an ant as a mascot. :) How about a cockroach? Beautifully engineered, indestructable, and they're *everywhere*... No thanks, I preferred the Weasel idea to this :P And why does it have to be an animal at all? I for one can't identify with any specimen of the *nix bestiary. Except maybe with the bsd daemon, but that's technically not a beast. But all those foxes, chameleons, penguins and what not -- I don't know. If an animal at all, I would definitely prefer a cockroach. But it's maybe hard to manufacture from plush. What about a tarantula? Fluffy by design. harry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
