Re: mktemp() patch

2000-06-20 Thread Daniel C. Sobral
Peter Jeremy wrote: On Sun, Jun 11, 2000 at 02:41:12AM +1000, Daniel C. Sobral wrote: Mind you, shells don't have problems with any character at all in a filename if they are properly written, but if you are expecting the filenames generated by mktemp() to be handled by shell, they ought to

Re: mktemp() patch

2000-06-18 Thread Peter Jeremy
As one of the proponents of the change, my apologies for not taking part in this thread earlier - I am way behind in my reading of most of the lists. On Thu, Jun 08, 2000 at 11:11:42AM +1000, Kris Kennaway wrote: Instead of using only alphabetic characters, the patch uses the following character

Re: mktemp() patch

2000-06-18 Thread Warner Losh
In message [EMAIL PROTECTED] "Jeroen C. van Gelderen" writes: : Pseudo random numbers are so cheap (or they should be) that you : just don't want to try and 'optimize' here. It is much better to : be conservative and use a good PRNG until it *proves* to be very : problematic. I disagree with

Re: mktemp() patch

2000-06-18 Thread Kris Kennaway
On Sun, 18 Jun 2000, Warner Losh wrote: In message [EMAIL PROTECTED] "Jeroen C. van Gelderen" writes: : Pseudo random numbers are so cheap (or they should be) that you : just don't want to try and 'optimize' here. It is much better to : be conservative and use a good PRNG until it *proves*

Re: mktemp() patch

2000-06-18 Thread Peter Jeremy
On 2000-Jun-19 12:03:40 +1000, Warner Losh [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] "Jeroen C. van Gelderen" writes: : Pseudo random numbers are so cheap (or they should be) that you : just don't want to try and 'optimize' here. It is much better to : be conservative and use a good

Re: mktemp() patch

2000-06-18 Thread Warner Losh
In message [EMAIL PROTECTED] Peter Jeremy writes: : On 2000-Jun-19 12:03:40 +1000, Warner Losh [EMAIL PROTECTED] wrote: : In message [EMAIL PROTECTED] "Jeroen C. van Gelderen" writes: : : Pseudo random numbers are so cheap (or they should be) that you : : just don't want to try and 'optimize'

Re: mktemp() patch

2000-06-12 Thread Kris Kennaway
On Sun, 11 Jun 2000, Matthew Dillon wrote: There's reasonable, and there's overkill. mktemp() has no business using punctuation in the temporary file names. :You guys are responding to old messages..I've already changed my mind :about this. Kris -- In God we Trust -- all others

Re: mktemp() patch

2000-06-11 Thread Mark Murray
Think about it. If you mix a random number with a non-random number, using xor, what you get is a random number. It's neither stronger nor weaker. No, you'll get weaker random number, it badly affects random distribution. OR or AND will affect more. What you say is

Re: mktemp() patch

2000-06-11 Thread Mark Murray
Only if predictable have the same bits number as random. If not all bits of random XOR-ed (i.e. half of random), it becomes weaker. Sigh. Exactly. The other half is _not_random_; I am not talking about it. BTW, if they have the same bits number, there is no reason to XOR random with

Re: mktemp() patch

2000-06-11 Thread Mark Murray
If it not weakers I can't see why it strenghthens. I.e. you can constantly strenghthens generator with passing it through XOR -1 ? If not, why any other value is better than -1? Huh? -1 is a constant, not random. Pass your data through _random_ bits, XORing it with them, and you have

Re: mktemp() patch

2000-06-11 Thread Mark Murray
BTW, if they have the same bits number, there is no reason to XOR random with predictable, random is not become more random. But still confirm this. If the random number is truly random, then you are correct. If there are attacks on your random number generator, then XORing other stuff

Re: mktemp() patch

2000-06-11 Thread Andrey A. Chernov
On Sun, Jun 11, 2000 at 09:24:37AM +0200, Mark Murray wrote: If it not weakers I can't see why it strenghthens. I.e. you can constantly strenghthens generator with passing it through XOR -1 ? If not, why any other value is better than -1? Huh? -1 is a constant, not random. Pass your

Re: mktemp() patch

2000-06-11 Thread Mark Murray
Huh? -1 is a constant, not random. Pass your data through _random_ bits, XORing it with them, and you have unbreakable crypto (one-time-pad) if you make a record of the random bits (the key). Yes, if passing _random_ through -1 _data_ not makes it strengthens, passing through

Re: mktemp() patch

2000-06-11 Thread David Scheidt
On Wed, 7 Jun 2000, Kris Kennaway wrote: :This patch was developed by Peter Jeremy and myself and increases the :number of possible temporary filenames which can be generated by the :mktemp() family, by more densely encoding the PID and using a larger set :of characters to randomly pad with. :

Re: mktemp() patch

2000-06-11 Thread Peter Wemm
David Scheidt wrote: On Wed, 7 Jun 2000, Kris Kennaway wrote: :This patch was developed by Peter Jeremy and myself and increases the :number of possible temporary filenames which can be generated by the :mktemp() family, by more densely encoding the PID and using a larger set :of

Re: mktemp() patch

2000-06-11 Thread Kris Kennaway
On Sun, 11 Jun 2000, Peter Wemm wrote: These could matter in the light of mktemp(1). file=`mktemp foo.` You guys are responding to old messages..I've already changed my mind about this. Why 74 characters? Why not 64? The more characters we have in the sample set the larger the

Re: mktemp() patch

2000-06-11 Thread Matthew Dillon
:You guys are responding to old messages..I've already changed my mind :about this. : : Why 74 characters? Why not 64? : :The more characters we have in the sample set the larger the namespace and :the better the statistical protection afforded by mktemp() : :Kris There's reasonable, and

Re: mktemp() patch

2000-06-10 Thread Bruce Evans
On Fri, 9 Jun 2000, Kris Kennaway wrote: dotfiles for example). I don't believe there's such a thing as a lowest common denominator of file system naming conventions - either a filesystem can support UFS names (perhaps through a translation later) or it's not suitable for running FreeBSD

Re: mktemp() patch

2000-06-10 Thread Andrey A. Chernov
On Fri, Jun 09, 2000 at 07:37:09PM -0400, Jeroen C. van Gelderen wrote: Why to XOR true random bits from arc4random() with non-random bits from getpid()? It only weakens. Better way is just remove any getpid() code and left arc4random() only. Then you will get collisions which you will

Re: mktemp() patch

2000-06-10 Thread Andrey A. Chernov
On Fri, Jun 09, 2000 at 11:23:58PM -0700, Andrey A. Chernov wrote: On Fri, Jun 09, 2000 at 07:37:09PM -0400, Jeroen C. van Gelderen wrote: Why to XOR true random bits from arc4random() with non-random bits from getpid()? It only weakens. Better way is just remove any getpid() code and

Re: mktemp() patch

2000-06-10 Thread Andrey A. Chernov
On Fri, Jun 09, 2000 at 11:23:58PM -0700, Andrey A. Chernov wrote: would be the way to go: 64^6 = 2^36 possibilities which is nice... 1) Just totally opposite: mixing random with non-random sources you'll get into collision much faster then with random source only. 2) Yet, of course,

Re: mktemp() patch

2000-06-10 Thread Matthew Dillon
:1) Just totally opposite: mixing random with non-random sources you'll get :into collision much faster then with random source only. 2) Yet, of course, :the code handles collisions. : :-- :Andrey A. Chernov :[EMAIL PROTECTED] Think about it. If you mix a random number with a non-random

Re: mktemp() patch

2000-06-10 Thread Mark Murray
Why not just XOR the whole lot into the current ${randomnumber}? That way, at least the effort of the whole calculation is not wasted as much. Why to XOR true random bits from arc4random() with non-random bits from getpid()? It only weakens. Better way is just remove any getpid() code

Re: mktemp() patch

2000-06-10 Thread Mark Murray
Then you will get collisions which you will have to deal with. I am not familiar with the code but if we can handle collisions nicely then that would be the way to go: 64^6 = 2^36 possibilities which is nice... 1) Just totally opposite: mixing random with non-random sources you'll get

Re: mktemp() patch

2000-06-10 Thread Garance A Drosihn
It's probably better to just get rid of the PID and use randomness throughout the name than to use 72 characters. 64^6 vs. 2*(72^3) . I seem to be in the minority on this, but in general I *like* the idea that the tempfiles include the pid. It's bad because it makes it easier for an evil-person

Re: mktemp() patch

2000-06-10 Thread Daniel C. Sobral
Kris Kennaway wrote: Bad example. Not _all_ filenames but temp. ones only which allows to run FreeBSD binary in MSDOS FS with MSDOS files. The point is the same. Files created by FreeBSD binaries during the course of operation don't conform to an 8.3 monocase naming scheme (think of

Re: mktemp() patch

2000-06-10 Thread Daniel C. Sobral
Kris Kennaway wrote: Instead of using only alphabetic characters, the patch uses the following character set: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ which is not believed to cause any problems with shells. The PID is also Huh? # does not cause

Re: mktemp() patch

2000-06-10 Thread Kris Kennaway
On Sat, 10 Jun 2000, Kris Kennaway wrote: Given the other replies in this thread I think I'll just remove the PID stuff altogether and make the temp filename only constructed from alphanumeric character. The price is that there's a chance of collision between two programs who mktemp() and

Re: mktemp() patch

2000-06-10 Thread Jeroen C. van Gelderen
Kris Kennaway wrote: On Sat, 10 Jun 2000, Kris Kennaway wrote: Given the other replies in this thread I think I'll just remove the PID stuff altogether and make the temp filename only constructed from alphanumeric character. The price is that there's a chance of collision between two

Re: mktemp() patch

2000-06-10 Thread Kris Kennaway
On Sat, 10 Jun 2000, Jeroen C. van Gelderen wrote: Actually, it's not of course a security risk in the new algorithm (this is mktemp() after all), but it's a potential failure mode which can cause applications to fail in ways they otherwise wouldn't (with some very low probability) on a

Re: mktemp() patch

2000-06-10 Thread Jeroen C. van Gelderen
Kris Kennaway wrote: On Sat, 10 Jun 2000, Jeroen C. van Gelderen wrote: Actually, it's not of course a security risk in the new algorithm (this is mktemp() after all), but it's a potential failure mode which can cause applications to fail in ways they otherwise wouldn't (with some

Re: mktemp() patch

2000-06-10 Thread Andrey A. Chernov
On Sat, Jun 10, 2000 at 02:31:23PM -0700, Kris Kennaway wrote: between two programs who mktemp() and come up with the same random filename, which is a theoretical security risk (at present only something with the same PID can come up with a colliding tempfile name) but the probability is

Re: mktemp() patch

2000-06-10 Thread Andrey A. Chernov
On Fri, Jun 09, 2000 at 11:53:34PM -0700, Matthew Dillon wrote: :1) Just totally opposite: mixing random with non-random sources you'll get :into collision much faster then with random source only. 2) Yet, of course, :the code handles collisions. : :-- :Andrey A. Chernov :[EMAIL

Re: mktemp() patch

2000-06-10 Thread Andrey A. Chernov
On Sat, Jun 10, 2000 at 09:31:49AM +0200, Mark Murray wrote: Incorrect. See my other mail; ${RANDOM} xor ${PREDICTABLE} is random. Only if predictable have the same bits number as random. If not all bits of random XOR-ed (i.e. half of random), it becomes weaker. BTW, if they have the same

Re: mktemp() patch

2000-06-10 Thread Andrey A. Chernov
On Sat, Jun 10, 2000 at 09:13:30AM +0200, Mark Murray wrote: Well, I tend to agree that it is not weakens random, but I not see any improvement too. That is a pretty fundamental theorem of Cryptography. My suggestion _strengthens_ the random number. All you lose is one bit if it If it not

Re: mktemp() patch

2000-06-10 Thread Andrey A. Chernov
On Sat, Jun 10, 2000 at 07:43:06PM -0700, Andrey A. Chernov wrote: On Sat, Jun 10, 2000 at 09:31:49AM +0200, Mark Murray wrote: Incorrect. See my other mail; ${RANDOM} xor ${PREDICTABLE} is random. Only if predictable have the same bits number as random. If not all bits of random XOR-ed

Re: mktemp() patch

2000-06-10 Thread Andrey A. Chernov
On Sat, Jun 10, 2000 at 07:36:10PM -0700, Andrey A. Chernov wrote: On Fri, Jun 09, 2000 at 11:53:34PM -0700, Matthew Dillon wrote: :1) Just totally opposite: mixing random with non-random sources you'll get :into collision much faster then with random source only. 2) Yet, of course,

Re: mktemp() patch

2000-06-09 Thread Garance A Drosihn
At 12:07 AM -0500 6/9/00, Dan Nelson wrote: I still suggest not using symbols at all, since I'd like to be able to quickly remove tempfiles by hand without worrying if I have to escape # or ^, etc. Uh, if I understand the update, the '#' is ALREADY used for this, in the current implementation.

Re: mktemp() patch

2000-06-09 Thread Boris Popov
On Thu, 8 Jun 2000, Kris Kennaway wrote: Count both, nwfs and smbfs, because any program can attempt to create temporary file on these filesystems. File with an invalid file name will be rejected, and this will cost an additional lookup operation(s). I'm not sure that weird

Re: mktemp() patch

2000-06-09 Thread John LoVerso
I still suggest not using symbols at all, since I'd like to be able to quickly remove tempfiles by hand without worrying if I have to escape # or ^, etc. Then disable globbing first. (csh et al) "set noglob" or (sh et al) "set -f noglob". John To Unsubscribe: send mail to [EMAIL PROTECTED]

Re: mktemp() patch

2000-06-09 Thread Jeroen C. van Gelderen
Mark Murray wrote: What is the purpose of this? It looks hugely wasteful to me. If you really need a single random bit, it is not good to waste a block of hard-gained gryptographic randomness; can you not use a pseudo-random bit-generator? arc4random() does not consume entropy

Re: mktemp() patch

2000-06-09 Thread Andrey A. Chernov
On Thu, Jun 08, 2000 at 08:47:36PM -0700, Kris Kennaway wrote: filesystems. For example, should we limit all FreeBSD file names to 8.3 single-case in case someone wants to run from an old-style MSDOS partition? Bad example. Not _all_ filenames but temp. ones only which allows to run FreeBSD

Re: mktemp() patch

2000-06-09 Thread Kris Kennaway
On Fri, 9 Jun 2000, Andrey A. Chernov wrote: On Thu, Jun 08, 2000 at 08:47:36PM -0700, Kris Kennaway wrote: filesystems. For example, should we limit all FreeBSD file names to 8.3 single-case in case someone wants to run from an old-style MSDOS partition? Bad example. Not _all_

Re: mktemp() patch

2000-06-09 Thread Kris Kennaway
On Fri, 9 Jun 2000, Kris Kennaway wrote: The point is the same. Files created by FreeBSD binaries during the course of operation don't conform to an 8.3 monocase naming scheme (think of dotfiles for example). I don't believe there's such a thing as a lowest common denominator of file system

Re: mktemp() patch

2000-06-09 Thread Mark Murray
But I repeat myself; are you still intending to use cryptographic security for one bit? What does that buy you? An attacker will laugh at the waste of resources that went into a coin-flip :-). Much better is to use something cheaper like time-of-day XOR 1 whatever. Pseudo random

Re: mktemp() patch

2000-06-09 Thread Andrey A. Chernov
On Fri, Jun 09, 2000 at 12:58:27PM -0700, Kris Kennaway wrote: Bad example. Not _all_ filenames but temp. ones only which allows to run FreeBSD binary in MSDOS FS with MSDOS files. The point is the same. Files created by FreeBSD binaries during the course of operation don't conform to an

Re: mktemp() patch

2000-06-09 Thread Andrey A. Chernov
On Fri, Jun 09, 2000 at 10:02:44PM +0200, Mark Murray wrote: But I repeat myself; are you still intending to use cryptographic security for one bit? What does that buy you? An attacker will laugh at the waste of resources that went into a coin-flip :-). Much better is to use something

Re: mktemp() patch

2000-06-09 Thread Jeroen C. van Gelderen
"Andrey A. Chernov" wrote: On Fri, Jun 09, 2000 at 10:02:44PM +0200, Mark Murray wrote: But I repeat myself; are you still intending to use cryptographic security for one bit? What does that buy you? An attacker will laugh at the waste of resources that went into a coin-flip :-).

Re: mktemp() patch

2000-06-09 Thread Jeroen C. van Gelderen
Kris Kennaway wrote: On Fri, 9 Jun 2000, Andrey A. Chernov wrote: On Thu, Jun 08, 2000 at 08:47:36PM -0700, Kris Kennaway wrote: filesystems. For example, should we limit all FreeBSD file names to 8.3 single-case in case someone wants to run from an old-style MSDOS partition?

Re: mktemp() patch

2000-06-08 Thread Matthew Dillon
: : Instead of using only alphabetic characters, the patch uses the following : character set: : : 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ : : Symbols '=' and '+' are prohibited in some other filesystems. It :is possible to avoid using them ? : :--

Re: mktemp() patch

2000-06-08 Thread Bruce Campbell
On Thu, 8 Jun 2000, Daniel O'Connor wrote: doconn On 08-Jun-00 Kris Kennaway wrote: doconn On Thu, 8 Jun 2000, Boris Popov wrote: doconn doconnInstead of using only alphabetic characters, the patch uses the following doconncharacter set: doconn

Re: mktemp() patch

2000-06-08 Thread Mark Murray
Hi + /* Encode the PID (with 1 bit of randomness) into 3 base-64 chars */ + pid = getpid() | (arc4random() 0x0002); What is the purpose of this? It looks hugely wasteful to me. If you really need a single random bit, it is not good to waste a block of hard-gained gryptographic

Re: mktemp() patch

2000-06-08 Thread Kris Kennaway
On Thu, 8 Jun 2000, Mark Murray wrote: Hi + /* Encode the PID (with 1 bit of randomness) into 3 base-64 chars */ + pid = getpid() | (arc4random() 0x0002); What is the purpose of this? It looks hugely wasteful to me. If you really need a single random bit, it is not good to

Re: mktemp() patch

2000-06-08 Thread Jeroen Ruigrok van der Werven
-On [2608 03:12], Kris Kennaway ([EMAIL PROTECTED]) wrote: Instead of using only alphabetic characters, the patch uses the following character set: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ which is not believed to cause any problems with shells. The PID is

Re: mktemp() patch

2000-06-08 Thread Samuel Tardieu
On 8/06, Jeroen Ruigrok van der Werven wrote: | -On [2608 03:12], Kris Kennaway ([EMAIL PROTECTED]) wrote: | Instead of using only alphabetic characters, the patch uses the following | character set: | | 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ | | which

Re: mktemp() patch

2000-06-08 Thread Bruce Evans
On Wed, 7 Jun 2000, Kris Kennaway wrote: Instead of using only alphabetic characters, the patch uses the following character set: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ which is not believed to cause any problems with shells. The PID is also I think

Re: mktemp() patch

2000-06-08 Thread Andrey A. Chernov
On Thu, Jun 08, 2000 at 09:50:48PM +1000, Bruce Evans wrote: I think it should use only letters and digits. For 6 X's, this gives a namespace of size 52^6 provided the namespace is not gratuitously (?) reduced using the pid. Best variant will be to keep the name MSDOS FS 8.3 name safe. Why

Re: mktemp() patch

2000-06-08 Thread Mark Murray
What is the purpose of this? It looks hugely wasteful to me. If you really need a single random bit, it is not good to waste a block of hard-gained gryptographic randomness; can you not use a pseudo-random bit-generator? arc4random() does not consume entropy except the first time it is

Re: mktemp() patch

2000-06-08 Thread Garance A Drosihn
At 12:51 PM +0200 6/8/00, Samuel Tardieu wrote: On 8/06, Jeroen Ruigrok van der Werven wrote: | -On [2608 03:12], Kris Kennaway ([EMAIL PROTECTED]) wrote: | Instead of using only alphabetic characters, the patch uses the following | character set: | |

Re: mktemp() patch

2000-06-08 Thread John LoVerso
| which is not believed to cause any problems with shells. The PID is also | Some shells parse # as a deletion character if memory serves me right. Also ^ is used for substitutions in many shells (as in ^faulty^ok). Why would you care if some shell used the a character in some special way?

Re: mktemp() patch

2000-06-08 Thread Dan Nelson
In the last episode (Jun 08), John LoVerso said: Symbols '=' and '+' are prohibited in some other filesystems. Specific examples of filesystems supported by FreeBSD and likely used by programs invoking mktemp(), please! (I'm not sure that the NetWare filesystem counts!) But why wouldn't

Re: mktemp() patch

2000-06-08 Thread Boris Popov
On Thu, 8 Jun 2000, John LoVerso wrote: Symbols '=' and '+' are prohibited in some other filesystems. Specific examples of filesystems supported by FreeBSD and likely used by programs invoking mktemp(), please! (I'm not sure that the NetWare filesystem counts!) Count both, nwfs

Re: mktemp() patch

2000-06-08 Thread Kris Kennaway
On Fri, 9 Jun 2000, Boris Popov wrote: Count both, nwfs and smbfs, because any program can attempt to create temporary file on these filesystems. File with an invalid file name will be rejected, and this will cost an additional lookup operation(s). I'm not sure that weird filesystems

Re: mktemp() patch

2000-06-08 Thread Garance A Drosihn
At 8:47 PM -0700 6/8/00, Kris Kennaway wrote: On Fri, 9 Jun 2000, Boris Popov wrote: Count both, nwfs and smbfs, because any program can attempt to create temporary file on these filesystems. Files with an invalid file name will be rejected, and this will cost an additional lookup

Re: mktemp() patch

2000-06-08 Thread Dan Nelson
In the last episode (Jun 08), Kris Kennaway said: On Fri, 9 Jun 2000, Boris Popov wrote: Count both, nwfs and smbfs, because any program can attempt to create temporary file on these filesystems. File with an invalid file name will be rejected, and this will cost an additional lookup

Re: mktemp() patch

2000-06-07 Thread Boris Popov
On Wed, 7 Jun 2000, Kris Kennaway wrote: This patch was developed by Peter Jeremy and myself and increases the number of possible temporary filenames which can be generated by the mktemp() family, by more densely encoding the PID and using a larger set of characters to randomly pad with.

Re: mktemp() patch

2000-06-07 Thread Kris Kennaway
On Thu, 8 Jun 2000, Boris Popov wrote: Instead of using only alphabetic characters, the patch uses the following character set: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ Symbols '=' and '+' are prohibited in some other filesystems. It is

Re: mktemp() patch

2000-06-07 Thread Daniel O'Connor
On 08-Jun-00 Kris Kennaway wrote: On Thu, 8 Jun 2000, Boris Popov wrote: Instead of using only alphabetic characters, the patch uses the following character set: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ Symbols '=' and '+' are