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
 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

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 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

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 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...

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



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* 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

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 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...

The PRNG in question is arc4random() - which AFAIK rates as
"cryptographically strong".  I don't believe that mktemp(3) warrants
the use of /dev/random (or even /dev/urandom).

Peter



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



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' 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...
: 
: The PRNG in question is arc4random() - which AFAIK rates as
: "cryptographically strong".  I don't believe that mktemp(3) warrants
: the use of /dev/random (or even /dev/urandom).

I think we're in agreement.  I had thought I read it as "use
random(3)" for some reason

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



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 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

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 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

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 predictable, random is not become 
 more random.

If you doubt your randomness, XORing two quantities can improve it, if
there is coincidence of random/non-random bits.

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

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 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

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 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

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 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

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 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

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.
:
: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

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 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

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 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

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 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

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 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

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 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.

-- 
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

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
   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

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, 
 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

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 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

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 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

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 
 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

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 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

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
 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

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 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

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 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

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 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

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 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)

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

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 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

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 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

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 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

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 bits number,
there is no reason to XOR random with predictable, random is not become 
more random.

-- 
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

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 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

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 (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

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, 
  :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

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.  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

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 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?

Well, nwfs and smbfs filesystems usually used when one need to
integrate FreeBSD machine in the already existing environment. So, the
question is simple - do we need to help interoperability or not ?

8.3 format filenames are probably obsolete, and there is no reason
to support them because nearly all server platforms support long file
names.
 
 Basically, I think the answer is not to use a nwfs or smbfs filesystem as
 your TMPDIR :-)

With mktemp() function you can create tempoary files anywhere, not
just in TMPDIR.

--
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

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]
with "unsubscribe freebsd-current" in the body of the message



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 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

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 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

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_ 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

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 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

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 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

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 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

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
   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

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 :-). 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

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?
 
  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

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 ?
:
:--
: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

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
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

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 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

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 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

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 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

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 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

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 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

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 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

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 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

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:
| 
| 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~
| 
|  which is not believed to cause any problems with shells.
|
| 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).

I believe bash requires some kind of whitespace character (blank,
tab, newline) in front of the '#' before it will treat it as the
comment character.  I am not sure about other shells (people who
use other shells might want to check).

Similarly, I believe '^' is used for substitutions ONLY if it is
the first character in the line.  Ie, 'echo hello^to^you' does
not do any substitution on the previous line.

Since we know these characters are only being used in a filename,
and NOT as the first character of a filename, then we should not
have trouble using them.

I must admit I am not as comfortable using '+=,', and I think one
of '@' or ':' should go, just in case the file is used in some
context that reads blah@blah:blah as userid@hostname:fname
I would probably drop the '@', but if there is some other reason
to drop ':' then the '@' could probably stay.

At the same time, I do like to see the set expanded as much as
possible, without causing any problems.


---
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

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?  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

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 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

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 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

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 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

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 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

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
  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

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.
 
 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

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 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

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 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