Re: mktemp() patch
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 pass the IFS=':'; for file in $filelist test. Why? Isn't it equally valid to state that they ought to pass IFS='a'; for file in $filelist or setting IFS to any other random character? Because : is a standard separator. See, for instance, PATH. (And see the "mind you" part of my comment above :). -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Windows works, for sufficently small values of "works". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 set: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ This was discussed in -audit as well - and most of the points brought up here have already been discussed there. Peter, I hope I've got the right version of the patch Looks about right. The character set matches my last suggestion (the only other item was making base64 and padchar `const'). On Thu, Jun 08, 2000 at 04:08:18PM +1000, Matthew Dillon wrote: It would be a good idea to avoid any punctuation. Could you please provide some rationale for this statement. I agree there are valid reasons for not using some specific characters, but I don't see any justification for a blanket ban. On Fri, Jun 09, 2000 at 04:15:45AM +1000, Garance A Drosihn wrote: context that reads blah@blah:blah as userid@hostname:fname Good point. I hadn't considered the impact of letting [rs]cp loose on the output from mktemp. At the same time, I do like to see the set expanded as much as possible, without causing any problems. That was my rationale as well. I went through the 7-bit printable set and wiped out the characters I though would cause problems. On Thu, Jun 08, 2000 at 09:51:34PM +1000, Bruce Evans wrote: Why are we still using the pid? It is highly non-random. It was originally used to ensure a separate starting point for separate processes, The other advantage is that it was easy to locate and delete temp files associated with dead processes. Given the change to a BASE64 PID, this is no longer true and I agree with Kris that it can be dropped. If you need to clean up after dead processes, you'll need to use lsof or fstat to work out what files are still wanted. On Fri, Jun 09, 2000 at 01:48:20PM +1000, Kris Kennaway wrote: I'm not sure that weird filesystems are a valid argument against mktemp() naming - there are LOTS of UNIX code which assumes UNIX namespace conventions, and it's not just mktemp() which is going to break on weird 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? I agree with Kris here. I briefly considered the problem of support for non-UFS filesystems and decided that it was reasonable for standard Unix utilities to make use of the facilities offered by the native filesystem - ie UFS. In any case, I believe that mktemp(3) will always return a valid filename for the filesystem (though it might take some time to pick one). _gettemp() [the function underlying mktemp(3), mkstemp(3) etc] invokes lstat(2) on each sample path and requires that lstat() returns ENOENT for it to succeed. If lstat() is given an invalid pathname, it should return something like EINVAL - which will make _gettemp() try again. If a filesystem implementation returns ENOENT when given a pathname that is not valid on that filesystem, then the filesystem implementation is broken and should be fixed. Note that AFAIK, currently FreeBSD cannot meet mkstemp guarantees on _any_ non-local filesystem (and some shared filesystem types) because the relevant locking mechanisms either don't exist or don't work. On Fri, Jun 09, 2000 at 02:57:02PM +1000, Garance A Drosihn wrote: Should the new mktemp check some kind of environment variable, and use a different list (or maybe even a totally different algorithm) depending on the value? I think that selecting between a number of different algorithms based on an environment variable might be over-kill. However it could be useful to allow the user to control the character set used by mktemp() via an environment variable. For example MKTEMP_CHARSET="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz._-" would give you the POSIX portable filename character set (apart from the `no leading hyphen' bit). Maybe support two variables - one to defines the allowable initial characters and another to define the allowable following characters if it's different. The downside is that this means that the user can pretty much control the temporary filenames used by processes - which means it would need to be disabled for setuid (and maybe setgid) processes. On Fri, Jun 09, 2000 at 03:08:57PM +1000, 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. ... I'd rather stick with easy-to-read and type tempnames. `easy-to-read and type' is basically incompatible with `hard-to-guess'. I'd suggest that most people will be deleting mktemp filenames using wildcards, shell-completion or cut-and-paste. Any shell that can't understand a filename that it has globbed is broken. Similarly, any shell that
Re: mktemp() patch
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* to be very : problematic. I disagree with this strongly. PRNG have proven time and time again to weaken security due to their less than random nature. It is my judgement that going down this path would be very bad, especially when cryptographically strong random number generators exist and are part of the base FreeBSD system. We should just use those... Actually thats what Jeroen was referring to - use of arc4random(). It's still a PRNG :-) Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 true only if second XOR part is 0 or -1 or changed between them or simple constant. I.e. if not _all_ bits XORed in the same way, it affects. Andrey, this is simply not true. A fundamental theorem of randomness is that random bits XORed onto your data is random. How do you think a one-time-pad works? I suggest you read Bruce Schneier's Cryptography book before continuing this debate. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 unbreakable crypto (one-time-pad) if you make a record of the random bits (the key). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 onto it will perturb the result and help defences. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 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 1,2,3,4... _data_ will not makes it strenghthens too. If attacker tries to predict random number generator itself and know pid and mktemp() algorithm, adding getpid() bits he already know will not stop him from this attack unless you plan to keep mktemp() algorihtm secret. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 1,2,3,4... _data_ will not makes it strenghthens too. Right, but the attacker doesn't always have access to the pid, so while it is _not_very_ random, under some circumstances it has _some_ useful randomness. If attacker tries to predict random number generator itself and know pid and mktemp() algorithm, adding getpid() bits he already know will not stop him from this attack unless you plan to keep mktemp() algorihtm secret. Correct. However if you are collecting bits of randomness (or suspected randomness) from various sources, XORing them together is a cheap way of of combining them and obfuscating them, without making the total randomness any worse than the best of them. There are ways (eg: hash algorithms) of adding the total randomness. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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. : :Instead of using only alphabetic characters, the patch uses the following :character set: : :0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ ":" is path seperator in Apple's HFS filesystem. "@" is used as the line erase character in some shells. "#" is rubout in some shells. David Scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 characters to randomly pad with. : :Instead of using only alphabetic characters, the patch uses the following :character set: : :0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ ":" is path seperator in Apple's HFS filesystem. "@" is used as the line erase character in some shells. "#" is rubout in some shells. # is a comment ~ at the beginning is a ~username ^ is an alias for | in old shells These could matter in the light of mktemp(1). file=`mktemp foo.` Why 74 characters? Why not 64? Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 namespace and the better the statistical protection afforded by mktemp() Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
: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 there's overkill. mktemp() has no business using punctuation in the temporary file names. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 from. There is the POSIX.1 portable filename character set: [A-Za-z._-] (from which the hyphen shall not be used as the first character of a portable filename). There are the POSIX NAME_MAX and pathconf(path, _SC_NAME_MAX) test features. NAME_MAX may be as low as 14 on POSIX systems. It is a small step from 14 to 11 or 8 to support non-POSIX 8.3 filenames. Very few programs actually support systems with variable or short filenames. patch(1) is one. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 left arc4random() only. 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 into collision much faster then with random source only. To clarify this: I mean getpid() ^ arc4random() suggestion only. Current variant is more complex because part of name is getpid() to avoid collision and part is random. But avoiding collision in this way is less secure because it is more predictable for attacker. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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, the code handles collisions. Part 2) need to be clarified too. The code _attempt_ to handle collision, but collision race can occurse between two processes checking for collision, so getpid() insertion prevents this. I am not against of removing getpid() code totally, just against of "randomization" of it, suggested in the patch, which increase collision chance. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
: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 number, using xor, what you get is a random number. It's neither stronger nor weaker. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 and
left arc4random() only.
Rubbish. A XOR B is random if at least one of A or B is random.
That is a pretty fundamental theorem of Cryptography. My suggestion
_strengthens_ the random number. All you lose is one bit if it
turns out that BOTH A and B are random, because they get combined
into one.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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
into collision much faster then with random source only. 2) Yet, of course,
the code handles collisions.
Incorrect. See my other mail; ${RANDOM} xor ${PREDICTABLE} is random.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 to guess what the next tempfile will be, but it's nice in after-the-fact situations, where there are a bunch of tempfiles left over, and you're wondering which ones are related (in the sense of having come from the same process, and you can then check if the process is still running). Not a big issue for me, as I doubt I have taken advantage of this more often than about once every two years, but I thought I would at least mention it. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 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 from. With this line of reasoning, why don't you go all the way and add control characters and stuff? They are allowed by ufs, and shell even grok them. In fact, commands such as ls even have flags to deal with them. Kris, IT IS THE APPLICATION THAT DICTATE YOUR NEEDS. The reasoning above would more likely get FreeBSD to be discarded than the FS. If the OS won't bend to the users' need, it will get dumped, period. As we position FreeBSD as a server system, the need to support foreign filesystems WELL increases. FIOFO (with all due respect :). mktemp() makes temp files in any directory including current one. Yes, but in practice it's not used that way since you can't write to most directories on the system except ~ and /tmp and relatives. Tell that to vim. :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Hmmm - I have to go check this. My reality assumptions are shattered. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 problems? : does not cause problems? 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 pass the IFS=':'; for file in $filelist test. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Hmmm - I have to go check this. My reality assumptions are shattered. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 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 altogether pretty small. I'll do some calculations to estimate the exact level of risk here. 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 normal system. But, I don't think it's a big enough problem to worry about (numbers still coming :-) Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 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 altogether pretty small. I'll do some calculations to estimate the exact level of risk here. 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 normal system. But, I don't think it's a big enough problem to worry about (numbers still coming :-) It's not a new situation, any application that can write to /tmp can create files that collide with other program's use of mktemp(). Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _ \_ _(_) (_)/_\_| \ _|/' \/ (_)(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 very low probability) on a normal system. But, I don't think it's a big enough problem to worry about (numbers still coming :-) It's not a new situation, any application that can write to /tmp can create files that collide with other program's use of mktemp(). Not under the current mktemp() since the PID is unique (except for wraparounds) mktemp() is not the only function that creates files in /tmp. Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _ \_ _(_) (_)/_\_| \ _|/' \/ (_)(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 altogether pretty small. I'll do some calculations to estimate the exact level of risk here. Please note that you turn never probavility into small one, and it is degradation. "never" is not completely never, of course, but if temp file stays until pids wrapped. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 PROTECTED] 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 true only if second XOR part is 0 or -1 or changed between them or simple constant. I.e. if not _all_ bits XORed in the same way, it affects. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 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? -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 (i.e. half of random), it becomes weaker.
Forget this, I change my mind here.
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.
--
Andrey A. Chernov
[EMAIL PROTECTED]
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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, :the code handles collisions. : :-- :Andrey A. Chernov :[EMAIL PROTECTED] 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. Forget this, I change my mind. It is not weaker, but not strengtenth too. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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. If you haven't been having any trouble with it for the past few years, it seems odd to worry about it with the new implementation. Also, you do not have to worry about '^' in the middle of a filename. That is only significant when it's the first character of the line. Yes, someone might worry about it the first time they go to delete a file with one of those characters in it's name, but it won't take too long before they learn either to just 'rm blah*' or they'll learn that they do not have to worry about it. Just MO. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 except the first time it is called and when explicitly reseeded through arc4random_stir(). Apart from that it's a deterministic function (the arc4 stream cipher), but it's still a reasonably good cryptographic PRNG because arc4 is a cryptographically strong algorithm. 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 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. Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _ \_ _(_) (_)/_\_| \ _|/' \/ (_)(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 binary in MSDOS FS with MSDOS files. Basically, I think the answer is not to use a nwfs or smbfs filesystem as your TMPDIR :-) mktemp() makes temp files in any directory including current one. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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_ 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 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 from. Basically, I think the answer is not to use a nwfs or smbfs filesystem as your TMPDIR :-) mktemp() makes temp files in any directory including current one. Yes, but in practice it's not used that way since you can't write to most directories on the system except ~ and /tmp and relatives. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 naming conventions - either a filesystem can support UFS names (perhaps through a translation later) or it's not layer suitable for running FreeBSD from. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 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.
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.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 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 naming conventions - either a filesystem can support UFS names (perhaps through a translation later) or it's not suitable for running FreeBSD from. Dotfiles usually created in user's home directory which is in UFS. What I mean is simple processing using temp files, consider running zip or unzip binaries. Proper way will be to sense FS name/abilitites and tune available charset in accordance with them. mktemp() makes temp files in any directory including current one. Yes, but in practice it's not used that way since you can't write to most directories on the system except ~ and /tmp and relatives. I don't care about /tmp which is in UFS, I care about current directory. Probably /tmp-prefix sensing code helps to solve this. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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
cheaper like time-of-day XOR 1 whatever.
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.
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 and
left arc4random() only.
--
Andrey A. Chernov
[EMAIL PROTECTED]
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
"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 :-). Much better is to use something
cheaper like time-of-day XOR 1 whatever.
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.
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.
Good point, there is no need to throw them away indeed.
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 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...
Cheers,
Jeroen
--
Jeroen C. van Gelderen o _ _ _
[EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_)
_ \_ _(_) (_)/_\_| \ _|/' \/
(_)(_) (_)(_) (_)(_)' _\o_
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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? 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 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 from. There really is no reason to use 72 characters instead of -say- 64. The increase in security is marginal and if the side-effect of using 64 is that it works with more filesystems than that is a Good Thing (TM). We are not alone in this world as -say- Microsoft tends to think. It's probably better to just get rid of the PID and use randomness troughout the name than to use 72 characters. 64^6 vs. 2*(72^3) . Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _ \_ _(_) (_)/_\_| \ _|/' \/ (_)(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
: : 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 ? : :-- :Boris Popov :http://www.butya.kz/~bp/ It would be a good idea to avoid any punctuation. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ doconn Symbols '=' and '+' are prohibited in some other filesystems. It doconn is possible to avoid using them ? doconn Yes, but at the expense of weakening the number of possible random doconn filenames :-( doconn doconn IMHO the loss of 2 characters doesn't greatly reduce the number of doconn possibilities, but it DOES greatly reduce the chance of an obscure error doconn message appearing when you try and make a temp file on a brain dead FS. mkstemp() actually creates the file if possible. If the creation of the file fails (and not due to race condition), retry the algorithm without 'suspect' characters. That way, you don't lose out on the extra 13% of possibilities when running on a 'real' filesystem ;) Since mktemp() only returns the suggested filename, you lose, unless mktemp() starts examining the mounted filesystems for known character no-nos. Its a pity that one cannot pass the allowable list of characters to mktemp() and related functions. --==-- Bruce. Common Sense, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 randomness; can you not use a pseudo-random bit-generator? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 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 called and when explicitly reseeded through arc4random_stir(). Apart from that it's a deterministic function (the arc4 stream cipher), but it's still a reasonably good cryptographic PRNG because arc4 is a cryptographically strong algorithm. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
-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 also Some shells parse # as a deletion character if memory serves me right. I think I noticed this behaviour when I started using zsh a few weeks ago after ksh. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED]VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl ...fools rush in where Angels fear to tread. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 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. | I think I noticed this behaviour when I started using zsh a few weeks | ago after ksh. Also ^ is used for substitutions in many shells (as in ^faulty^ok). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 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.
Index: mktemp.c
===
RCS file: /home/ncvs/src/lib/libc/stdio/mktemp.c,v
retrieving revision 1.19
diff -u -r1.19 mktemp.c
--- mktemp.c 2000/01/27 23:06:46 1.19
+++ mktemp.c 2000/06/08 00:57:17
...
@@ -120,20 +127,22 @@
errno = EINVAL;
return (0);
}
- pid = getpid();
- while (*trv == 'X' pid != 0) {
- *trv-- = (pid % 10) + '0';
- pid /= 10;
+
+ /* Encode the PID (with 1 bit of randomness) into 3 base-64 chars */
+ pid = getpid() | (arc4random() 0x0002);
+ for (n = 0; *trv == 'X' n 3; n++) {
+ *trv-- = base64[pid 0x3f];
+ pid = 6;
}
Why are we still using the pid? It is highly non-random. It was originally
used to ensure a separate starting point for separate processes, and because
there was no truly random RNG. Now, arc4random() is hopefully random enough
to give a good starting point by itself. It is a feature (a consequence of
true randomness) that it may give identical starting points for separate
processes.
@@ -179,15 +188,11 @@
for (trv = start;;) {
if (*trv == '\0' || trv == suffp)
^^^ normal style
return(0);
- if (*trv == 'Z')
- *trv++ = 'a';
+ pad = strchr(padchar, *trv);
+ if (pad == NULL || !*++pad)
^ style bug
+ *trv++ = padchar[0];
else {
- if (isdigit((unsigned char)*trv))
- *trv = 'a';
- else if (*trv == 'z') /* inc from z to A */
- *trv = 'A';
- else
- ++*trv;
+ *trv++ = *pad;
break;
}
}
This finishes bogotifying the comment before the for loop:
/* tricky little algorithm for backward compatibility */
Don't forget to remove it :-). The algorithm is now a simple increment
in base strlen(padchar). Perhaps it should use a random increment
initially if there aren't enough X's to provide enough randomness in
the starting point, or always. All cases do slow filesystem syscalls,
so it might be cheap enough to randomize the whole path every time.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 are we still using the pid? It is highly non-random. It was originally I agree. We must not use getpid() since we have arc4random(). -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 called and when explicitly reseeded through arc4random_stir(). Apart from that it's a deterministic function (the arc4 stream cipher), but it's still a reasonably good cryptographic PRNG because arc4 is a cryptographically strong algorithm. 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. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
| 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? In general, you are not going to be typing the filename generated by mktemp() et al. And when you do, use the shell's strong quote (ala ') to escape such characters. (before someone mentions, almost none of these restrictions apply to scripts) 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!) John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 it count? If I mount a Netware volume and decide to edit a file with an editor that creates a temporary filename for some reason, I'd like it to work. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 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). -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 are a valid argument against mktemp() naming - there are LOTS of UNIX code which assumes UNIX namespace conventions, and it's not just mktemp() which is going to break on weird 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? Basically, I think the answer is not to use a nwfs or smbfs filesystem as your TMPDIR :-) Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 operation(s). I'm not sure that weird filesystems are a valid argument against mktemp() naming - there are LOTS of UNIX code which assumes UNIX namespace conventions, and it's not just mktemp() which is going to break on weird 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? Basically, I think the answer is not to use a nwfs or smbfs filesystem as your TMPDIR :-) Certainly the new version should not worry about any problems (such as 8.3) which are just as much of a "problem" with the current implementation. A thought occurs to me, and it's vile enough that I would not feel insulted if everyone unanimously shouts it down. However, thoughts occur to me so rarely that I feel compelled to share them if there is any chance they might be useful. Should the new mktemp check some kind of environment variable, and use a different list (or maybe even a totally different algorithm) depending on the value? Perhaps have a few specific choices, where even the "least random" option would at least add a few characters to the current list. Maybe have the "most random" option completely drop more of the the UID part, and use that space for more randomly-generated bits? Honest, I won't feel bad if everyone hates this idea or laughs at the absurdity of it...:-) --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 operation(s). I'm not sure that weird filesystems are a valid argument against mktemp() naming - there are LOTS of UNIX code which assumes UNIX namespace conventions, and it's not just mktemp() which is going to break on weird 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? 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. Considering the great jump in randomness between the orginal and the proposed (65536 - 916132832 just using [A-Za-z0-9] ), I'd rather stick with easy-to-read and type tempnames. Basically, I think the answer is not to use a nwfs or smbfs filesystem as your TMPDIR :-) mktemp() doesn't use TMPDIR; the user gets to pass a template of his choosing, which could reasonably be just "bobX.tmp". -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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. 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 ? -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 possible to avoid using them ? Yes, but at the expense of weakening the number of possible random filenames :-( Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mktemp() patch
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 prohibited in some other filesystems. It is possible to avoid using them ? Yes, but at the expense of weakening the number of possible random filenames :-( IMHO the loss of 2 characters doesn't greatly reduce the number of possibilities, but it DOES greatly reduce the chance of an obscure error message appearing when you try and make a temp file on a brain dead FS. BTW.. For 5 character long temp names with + and = the number of possibile names is 2073071593, without it is 1804229351. (13% less) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
