Re: cvs mv
On 2/19/06, Jakub Bogusz [EMAIL PROTECTED] wrote: mv SPECS/kernel-net-rt2x00.spec,v SPECS/rt2x00.spec,v Done. -- Michal Moskal, http://nemerle.org/~malekith/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: cvs vs svn... (Re: SOURCES: ghostscript-afpl-am.patch (NEW), ghostscript-afpl-ijs_pkg...)
On 9/6/05, Jan Rekorajski [EMAIL PROTECTED] wrote: On Tue, 06 Sep 2005, wrobell wrote: On Tue, 2005-09-06 at 18:46 +0200, Michal Kochanowicz wrote: On Tue, Sep 06, 2005 at 05:32:50PM +0100, wrobell wrote: let's start new war... what about moving repo to svn? Any reasons? SVN sucks a big one. svn diff without performing connection to remote server. At the cost of keeping ALL tags/branches locally. You're joking. Why would anyone store all branches and tags locally? Tagging can be done by svn cp http://somewhere/trunk http://somewhere/tags/some-tag and moving to a new branch can be done with svn switch http://somewhere/branches/some-branch. The results are much like with cvs. -- Michal Moskal, http://nemerle.org/~malekith/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [EMAIL PROTECTED]: DISTFILES: ERRORS: lkcp-0.5.3.tar.bz2]
On 8/26/05, Adam Gołębiowski [EMAIL PROTECTED] wrote: On Thu, Aug 25, 2005 at 10:34:26AM +0200, Arkadiusz Miskiewicz wrote: On Wednesday 24 of August 2005 18:42, Adam Gołębiowski wrote: I was just about to commit a fix to cvs::admin/distfiles/file-fetcher.pl but thought it was better to ask. So, do we want to add that --no-check-certificate option? After all, it's the developer who should verify given site. +1 Ok, done. Do we have distfiles admin? malekith (cc-ed)? cvs up done. -- Michal Moskal, http://nemerle.org/~malekith/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: passwdgen
On 8/6/05, Tomasz Grobelny [EMAIL PROTECTED] wrote: Dnia \u015broda 03 sierpnia 2005 13:06, maHo wrote: Hello #v+ $ passwdgen -1p@ --min=4 --max=6 #v- and it hangs. Because it uses /dev/random which is not very efficient (see strace). Would it be correct to use /dev/urandom? Does it contain the same amount of entropy or is it somehow simpler (and possibly less secure)? It depends on how paranoid you are. If you believe NSA, FSB or some other kind of highly intelligent aliens are going to reverse SHA-1, so they can guess next password based of the previous one then you should definitely use /dev/random. OTOH if you believe it you should be also aware they could be controlling you from space using one of these satellites... /dev/random makes sure it doesn't leak more entropy than it gets, so it is impossible to guess anything without knowing the entropy (sic!). Which isn't entropy anyway, so CIA/KGB/etc can intercept it. -- Michal Moskal, http://nemerle.org/~malekith/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: passwdgen
On 8/6/05, Tomasz Grobelny [EMAIL PROTECTED] wrote: Dnia sobota 06 sierpnia 2005 17:50, Michal Moskal napisa\u0142: On 8/6/05, Tomasz Grobelny [EMAIL PROTECTED] wrote: Dnia \u015broda 03 sierpnia 2005 13:06, maHo wrote: Hello #v+ $ passwdgen -1p@ --min=4 --max=6 #v- and it hangs. Because it uses /dev/random which is not very efficient (see strace). Would it be correct to use /dev/urandom? Does it contain the same amount of entropy or is it somehow simpler (and possibly less secure)? It depends on how paranoid you are. If you believe NSA, FSB or some other kind of highly intelligent aliens are going to reverse SHA-1, so they can guess next password based of the previous one then you should definitely use /dev/random. OTOH if you believe it you should be also Ok, but would you trust a password generator that is based on rand function from glibc (which in turn returns values based only on system time)? If somebody knew you use this password generator he would have to check only several hundred thousands passwords to hit the right one. That would be a major security flaw. Thus the questions are: 1. How secure is /dev/urandom? Is is closer to /dev/random or to rand()? It's far closer to /dev/random. In the second paragraph I explained it -- /dev/urandom is the same as /dev/random except it doesn't enforce that you read only as much as you (well, the kernel) write to it. So if it lacks new random data, it will generate it based on what's in the pool. 2. Should (according to specs) /dev/random be more secure than /dev/urandom? Yes, because it doesn't require SHA-1 function to be irreversible. This is however quite a good assumption. 3. If /dev/urandom is supposed to be less secure but it is secure enough (in current kernel implementation) should passwdgen use it? Yes, because it works. No, because it could be insecure if kernel behaviour changes. Other opinions? It cannot change to be less secure. It's part of the kernel API. -- Michal Moskal, http://nemerle.org/~malekith/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: passwdgen
On 8/6/05, Tomasz Grobelny [EMAIL PROTECTED] wrote: Dnia sobota 06 sierpnia 2005 18:49, Michal Moskal napisał: On 8/6/05, Tomasz Grobelny [EMAIL PROTECTED] wrote: 1. How secure is /dev/urandom? Is is closer to /dev/random or to rand()? It's far closer to /dev/random. In the second paragraph I explained it -- /dev/urandom is the same as /dev/random except it doesn't enforce that you read only as much as you (well, the kernel) write to it. So if it lacks new random data, it will generate it based on what's in the pool. So it is hard enough to predict data that was read from /dev/urandom in the past? I would say so. But maybe I'm not paranoid ENOUGH. If so, maybe a patch for passwdgen to use /dev/urandom should be created? Maybe a flag? 3. If /dev/urandom is supposed to be less secure but it is secure enough (in current kernel implementation) should passwdgen use it? Yes, because it works. No, because it could be insecure if kernel behaviour changes. Other opinions? It cannot change to be less secure. It's part of the kernel API. Does the API define how data coming from /dev/urandom is generated? man urandom: When read, /dev/urandom device will return as many bytes as are requested. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current non-classified liter- ature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead. -- Michal Moskal, http://nemerle.org/~malekith/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: mv SPECS/trustees2.6.spec,v SPECS/trustees.spec,v
On 7/23/05, Zbyniu Krzystolik [EMAIL PROTECTED] wrote: Hello, project name is just trustees, so $subject please. Done. -- Michal Moskal, http://nemerle.org/~malekith/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
