Re: SVN migration?

[Dirk-Willem van Gulik]

On Fri, 4 Feb 2005, Henri Yandell wrote:

> I've not heard anything about it being mandatory yet, but the numbers
> speak for themselves.

It is not mandatory at this time. And won't be anytime soon.

> So I assume at some point there'll be pressure to turn off the CVS server.

There is that - as this is a volunteer ran service - and warm bodies are
always in short supply.

But then again - as long as there are volunteers from communities using
CVS expect the kettle to not come to a boil.

Ultimately -each- project needs to make their own deceisions as to what
tools and techniques they use; the ASF is merely a supprint and legal
backbone and container.

However SVN is a bit more modern than CVS - so you may also have some
internal reasons to move to SVN at some point - see the usual cvs v.s. svn
google pages.

Dw

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: License files error

[Dirk-Willem van Gulik]

On Tue, 23 Dec 2003, Mark Thomas wrote:

> A lot of the license files in tomcat have the following lines:
>
>  * 1. Redistributions of source code  must retain the above copyright notice *
>  *notice, this list of conditions and the following disclaimer.  *
>
> Note that "notice" appears at the end of the first line as well as the
> beginning of the second.

Ok - no problem, genuine error - permission for a committer to fix this;
BUT I strongly suggest to play it safe and follow this procedure:

->  post a patch _first_, Cc: the PMC and [EMAIL PROTECTED]

and then

->  commit exactly that patch after a quick OK from your PMC.

Make sure there are no other changes in that commit - no code, nothing
(except perhaps something like the CHANGES file) but the above fix and
make sure there is a nice log message saying what was changed to the
license and why ;-)

Sorry to be overly careful; but the last time we had such a 'quick and
trivial fix' we lost a few lines out of the disclaimer in a few files by
accident due to \r\n inconsistency and it took us a while to notice.

Dw

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: License files error

[Dirk-Willem van Gulik]

On Tue, 23 Dec 2003, Mark Thomas wrote:

> them with the official version (http://www.apache.org/LICENSE)? I ask since I
> don't want to change the license file in case there are any legal
> complications. I can't see why there would be but you never know - better safe
> than sorry ;)

You bet :-) Fiddling with the license, no matter how trivial, should be
checked, double checked, triple checked and approved first :-)

So what is the error ? I read on bug id #10286:

>  The LICENSE file contains a small grammatical error in the first
>  condition.  The word 'notice' is incorrectly repeated.

>From the license (1.1) file (http://www.apache.org/LICENSE):

 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.

What is the incorrect repeat ?

Dw
-- 
Dirk-Willem van Gulik, President of the ASF.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Order of parameters

[Dirk-Willem van Gulik]

On Wed, 8 Oct 2003, Chad Johnson wrote:

> A solution that could work:
>   Directly get the query string with "request.getQueryString()" parse
> the results yourself and store the results in the order found.

Come on - you folks are java guys - wrap something around it :-0

Dw

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Order of parameters

[Dirk-Willem van Gulik]

On Wed, 8 Oct 2003, Martin van Dijken wrote:

> I've been trying to create an automated form handler. This form handler
> could be a lot more effective if the request parameters were in the
> order they were put on the form. Now most browsers send this information

MOST browsers; certainly not all.

> over HTTP in the order they were found in the form. However, because the
> parameters are in Tomcat put into a Hashtable, the order is lost and can
> never be rebuilt.

Unfortunately it is not uncommon for anti-virus/filtering proxies to mess
with the order as well.

If you are requiring order it may makes the most sense to NOT trust the
wire - but do the ordering yourself on entry as described.

But bear in mind that it is generally much much safer to check for a
explicit field name in the Hash table than to rely even on the ordering; a
broken proxy (common) or some malicious person (less common) may have
removed or added fields.

So this idea may not be one which leads to safe habits.

DW

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Duplicate session IDs are *common*

[Dirk-Willem van Gulik]

On Sat, 11 Jan 2003, Phil Steitz wrote:

> Sorry, missed that.  You are correct (also about hashing being a cheap
> way to get randomization).

No, no; just unpredictability.

> An interesting challenge is how to keep the "uniqueness bits" either
> short enough so that the "random bits" give strong unpredictability by
> themselves; or to let the uniqueness bits somehow "contribute" to the
> unpredictability.

Ack; by feeding it into a cryptographic one way function which has a large
enough space; as surmized; 128 bits is propably enough.

> protection" and security. My personal opinion is that the best approach
> is to leave the keys "purely random" and to leave the recently added
> patch to test for duplicates in place.

Ack. In addition I personlly like the scheme where you can 'check' the ID
for validness; i.e. the scheme where you use

ID=hash( counter + secret + hisip ).counter

so you can short circuit naughty people if the hash does not match. As
I've seen many an abuse of this test of duplicates and seen it turned into
a DOS due to too much expensive database work at the back. You can
augement the above by adding the time of issuance, etc.

Dw.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Duplicate session IDs are *common*

[Dirk-Willem van Gulik]

On Fri, 10 Jan 2003, Costin Manolache wrote:

> I find it amazing that 2 people reported beeing hit by meteors (duplicate
> session ids ) in the same week.

Make that 3; I've seen this as well; I suspect this is becauce tomcat
saves the sessions across restarts; and then happens to re-generate them
in the same way on the second startup.

> You're right - a counter is better than time. It'll duplicate the counter
> if tomcat is restarted - so probably the initial value of the counter
> should be random or derived from time.

Well counter + time-of-tomcatstart + ip + port is very unique provided
the ip is in the public space.

Dw.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Duplicate session IDs are *common*

[Dirk-Willem van Gulik]

On Fri, 10 Jan 2003, Phil Steitz wrote:

> > Except that hash( i++ . secret).i is generally a lot cheaper and easier to

> Unfortunately, hashing blows away guaranteed uniqueness ("one-way" =>
> not 1-1), so if your last step is a hash, you will need to keep the

Hence the concatenation with 'i'. Or 'i' and the local ipaddress/port.

Dw.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Duplicate session IDs are *common*

[Dirk-Willem van Gulik]

On 10 Jan 2003, Eric Rescorla wrote:

> There's nothing wrong with what you propose, but it's sort of
> like saying "maybe I should wear a helmet at all times
> because a meteor might drop on my head". Sure, it could happen,
> btu it's not the thing I'd worry about.

Except that hash( i++ . secret).i is generally a lot cheaper and easier to
code cross platform than using a true cryptographic random generator with
the right tie in with hardware. And it happens to have a hard-hat aspect
thrown in as a freebee.

Dw


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Duplicate session IDs are *common*

[Dirk-Willem van Gulik]

> Securely random and unpredictable are effectively the same thing.

Depends on your definition; one-way-function((count++) + (secret)) is
quite unpredictable; expcet for those knowing the secret. Secure random
generators give you a value which is unpredictable for all. And are a lot
more expensive generally.

Dw


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Duplicate session IDs are *common*

[Dirk-Willem van Gulik]

> ID provides a statistical probability of collision so low that
> there is no need to explicitly check for uniqueness.

Or just add a syncronized i++ to make sure.

Dw.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Duplicate session IDs are *common*

[Dirk-Willem van Gulik]

On Fri, 10 Jan 2003, Glenn Olander wrote:

> 1) a good PRNG, such as secureRandom

Why does it need to be securely random; surely unpredicatable is good
enough ?

> 2) a uniqueness guarantee

count++ +":"+myip+":"+myport

is also quite unqiue :-)

DW.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Duplicate session IDs are *common*

[Dirk-Willem van Gulik]

On Fri, 10 Jan 2003, Jim Jagielski wrote:

> But it doesn't change the fact that randomness != uniqueness, which is
> what Glenn's point was I think.

Just as an example; doing on issue

syncronized count++;
id = count.ipaddr
add port if you must :-)

gives you a rather unique (but predictable) session id. The uniqueness of
the ipaddres obviously relies on the registry function of iana/ripe/et.al.
combined with your site/provider IP management.

or if it must be un-prediable do something like:

on init
seed = true-rand... or config-file-entry

on issue
id = md5( seed . count . ipaddr );

or if you do not trust md5's or find them too expensive

id = hash(seed.count.ipaddr).count.ipaddr
with hash = md4, md5, sha1, crypt, ..
as long as it is one way -and-
seed is truly random or manually choosen
to be proper.

OR if you want to check a session id prior to spending
(lookup) cycles on them to counter DoS0-s then do something like

id = hash(seed.count.hisip.ipaddr).count.ipaddr.hisip

and on accept do
hisip = from-accept-stack-info()
s,c,i1,i2 = splice(id)
i2 == hisip ?
i1 == myip ?
hash(seed.c.hisip.myip) == s ?
now do the expensive stuff

add a time-of-issue if needed if you are worried about that. Obviously now
the seed -must- be a config secret; as otherwise you cannot restart your
server without blowing all sessions out of the water.

Dw.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Duplicate session IDs are *common*

[Dirk-Willem van Gulik]

On Thu, 9 Jan 2003, Schnitzer, Jeff wrote:

> One thing to contemplate is that if you have 100,000 sessions and you
> get 10 new sessions created every second, that's the equivalent of 1
> million inadvertent hack attempts every single second.  Granted that's
> still small compared to the total size of a truly randomly generated
> 128-bit number, but I wouldn't run a banking application on it.

Am I right to understand that what is needed is only:

->  an unguessible ID ?
->  which is unique within a certain realm ?

If that is the case one can tailor the ID to do exactly that. And,
espcially, not a bit more.

Dw




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Duplicate session IDs are *common*

[Dirk-Willem van Gulik]

On 9 Jan 2003, Eric Rescorla wrote:

> Remy Maucherat <[EMAIL PROTECTED]> writes:
> > - A MD5 hash occurs after getting the SecureRandom. This looks like a
> > mistake, and decreases the quality of the random a lot, but given the
> > quality of MD5, that shouldn't be noticeable in the real world.

> I think that the MD5 is pointless but it shouldn't decrease the
> quality of the randomness to any interesting degree.

It makes the value less predictible. But as it adds no information (and
one could argule only looses it if the initial information had more than
128bits of randonm (which is highly unlikely)) it does not change the
'randomness' itself.

You propably want to argue -what- sort of randomness you want

-   unpredicable session id's
-   a unique session id
-   always a guaranteed different session id.
-   session id with no information.

Pick one, pick two, but if you pick three or more you are going to have a
hard time.

Dw


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

tcpNoDelay for http11/coyote connectors - but not for JK et.al.

[Dirk-Willem van Gulik]

Any special reason why the so-usefull (I am generating small gif's with a
quick turn around time) tcpNoDelay config directive is not (documented) as
available across all connectors ?

See  
http://developer.apple.com/techpubs/webobjects/ReleaseNotes/WO52RelNotes/WOJSPServlet.html
for a similar story.

Note that I am -not- arguing for it to be always true; just for it to be a
documented across-all-conenctors config directive. Or is there a deeper
reason as why it would be bad for mod_jk* to allow access to this ?

Dw


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Jakarta 2001 PMC: Last chance for correction of voter list.

[Dirk-Willem van Gulik]

-BEGIN PGP SIGNED MESSAGE-


Please find attached the list of voters eligible to vote in the 2002
Jakarta PMC. If you see showstopper's, serious typo, etc let us known
immediately. <[EMAIL PROTECTED]> is what will be used for the Ballot on
the 12th of February.

Errors are to be send to [EMAIL PROTECTED]

Dw.

Schedule Jakarta PMC 2002:

x   0:00 GMT  - 2002-2-7Nominations close

x   0:00 GMT  - 2002-2-9Publication of candidate list.
x   Publication of voter's list.

0:00 GMT  - 2002-2-12   Candidate list final and announced.
Voter's list final and announced.
Voters receive their ballots.
Ballot opens

0:00 GMT  - 2002-2-19   Ballot closes

0:00 GMT  - 2002-2-21   Voters receive confirmation of their vote

0:00 GMT  - 2002-2-22   Final tally made and published.
0:00 GMT  - 2002-2-22   Archive handed over to the ASF
board secretariat.

Abey M. Mullassery  abey
Andrew C. Oliveracoliver
Adam Murdochadammurdoch
Andreas V. Kempfakempf
Anil Vijendran  akv
Alex Chafee alex
Amy Roh amyroh
Anders Kristensen   anders
Andy Armstrong  andya
Andy Riedel ariedel
Arieh Markelarieh
Arnout Kuiper   arnout
Arron Bates arron
Arun Jamwal arun
Arundhati Bhowmick  aruna1
asmuts  asmuts
Juozas Baliuka  baliuka
Henri Yandell   bayard
Brendan Burns   bburns
B. C. Holmesbcholmes
Hans Bergsten   bergsten
Bill Barker billbarker
Bip Thelin  bip
Berin Loritsch  bloritsch
Stefan Bodewig  bodewig
Bojan Smojver   bojan
Jeff Brekke brekke
Brian Goetz briangoetz
Kevin Burtonburton
carlson carlson
Rich Catlettcatlett
Christopher Cainccain
Cedric Dumoulin cedric
Ceki Gulcu  ceki
Charles Benett  charlesb
Christopher Elkins  chrise
Christoph Wilhelms  chrisw
Carl Ludwig cl
Cory Hubert clhubert
Casey Lucas clucas
Christopher Lenzcmlenz
Eung-ju Parkcolus
Conor MacNeill  conor
Costin Manolachecostin
Craig R. McClanahan craigmcc
Cameron Riley   criley
Chris Taylorcstaylor
Doug Cuttingcutting
Carsten Ziegelercziegeler
Dan Milsteindanmil
Danny Angus danny
Danny Cowarddannyc
Darrell DeBoer  darrell
DaveB   daveb
Dave Kordavekor
Dave Bryson dbryson
Daniel F. Savarese  dfs
David Geary dgeary
Dion Gillarddion
Dirk Verbeeck   dirkv
Dave Polito djpolito
Donald Leslie   dleslie
Daniel Rall dlr
Dan Mandell dmandell
Dmitri Plotnikovdmitri
Dmitry Serebrennikovdmitrys
Eric Dobbs  dobbs
Peter Donalddonaldp
Eugene Gluzberg drag0n2
Doug Sale   dsale
Doug Davis  dug
James Duncan Davidson   duncan
David Weinrich  dweinr1
David Winterfeldt   dwinterfeldt
Ed Korthof  ed
Eduardo Pelegri-Llopart eduardop
Erik Hatcherehatcher
Eric Rescorla   ekr
Enver Haase enver
Federico Barbieri   fede
Fedor Karpelevitch  fedor
Gerhard Froehlich   froehlich
Vasile Gaburici gaburici
Geir Magnusson Jr.  geirm
Michael McCallumgholam
Giacomo Patigiacomo
Glenn Nielsen   glenn
Glenn McAllisterglennm
Glen Stampoultzis   glens
Gonzalo D Guallar   gonzalo
James Todd  gonzo
gerhard.schwarz gschwarz
Paul Hammanthammant
Harish Prabandham   harishp
Harmeet Bedihbedi
Henning Schmiedehausen  henning
GOMEZ Henri hgomez
Bernie Hoeneisenhoeneisen
Diane Holt  holtdl
Justyna Horwat  horwat
Ted Husted  husted
Ilkka Priha ilkka
ingoingo
jariw   jariw
Jazmin Jonson   jazmin
Jim Boutcherjboutcher
John Casturajcastura
Jeff Turner jefft
Sung-Gu Parkjericho
jean-frederic clere jfclere
Jason Hunterjhunter
Petr Jirickajiricka
Jean-Luc Rochat jluc
Jeff Martin jmartin
John McNallyjmcnally
Jim Moore   jmoore
Jon Stevens jon
Jonathan Locke  jonl
James Strachan  jstrachan
Juergen Pilljuergen
Jason van Zyl   jvanzyl
Keith Wannamakerkeith
Kevin Hammond   khammond
Kief Morris kief
Chris Kimpton   kimptoc
Kin-Man Chung   kinman
K

Announcement: JakartaPMC elections for 2002

[Dirk-Willem van Gulik]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Folks,

It is time for the yearly election of the Jakarta PMC by the
committers of Jakarta.

For a background - please take some time to read:

http://jakarta.apache.org/site/management.html

The Project Management Committee (PMC) was formed by the
Apache Board in September 1999. The number of PMC seats is
set at seven.

Annually, all seven seats will be up for renewal. The ASF
board will be asked to provide a person or persons to
administer the nominations and a subsequent ballot.

The administrator(s) will determine the mechanics of
the voting procedures. Any committer to any Jakarta code
base will be eligible to vote.

Once the new PMC is in place, the first order of business
will be to determine a chairperson from amongst their ranks.

The list of current members can be found in our Project Credits.

Scedule:

0:00 GMT  - 2002-2-7Nominations close
0:00 GMT  - 2002-2-9Publication of candidate list.
0:00 GMT  - 2002-2-9Publication of voter's list.
0:00 GMT  - 2002-2-12   Candidate list final and announced.
0:00 GMT  - 2002-2-12   Voter's list final and announced.
0:00 GMT  - 2002-2-12   Voters receive their ballots.
0:00 GMT  - 2002-2-12   Ballot opens
0:00 GMT  - 2002-2-19   Ballot closes
0:00 GMT  - 2002-2-21   Voters receive confirmation of their vote
0:00 GMT  - 2002-2-22   Final tally made and published.
0:00 GMT  - 2002-2-22   Archive handed over to the ASF
board secretariat.

Logistics for those elections (v1.02):

Volunteers: <[EMAIL PROTECTED]>
        Dirk-Willem van Gulik (0xEC140B81)
Jim Jagielski (0xA0BB71C1)
Ben Laurie (0x2719AF35)

Seat:   A mail folder on daedalus.apache.org
is used as the mail relay and time
reference for all communication.

T=0 The Announcement of the election is posted to

[EMAIL PROTECTED]
*[EMAIL PROTECTED]
[EMAIL PROTECTED]
and
an individual message to all people with commit
access to jakarta-* projects.

T+7 Nominations for PMC needs to be in by 0:00 GMT 7th of
February 2001. You can either nominate yourself - or
nominate someone else. What counts is the confirmation
from the nominee being received.

->  Posting a message to [EMAIL PROTECTED] and
Cc: [EMAIL PROTECTED] with your candidature, a short
description about who you are, what you want to
accomplish.

->  Or if you are volunteered by someone else - a similar
message confirming that you are accepting the
nomination - with again - some details about yourself.

->  PMC seats are open to anyone. Regardless as to
wether you are a committer, lurker or coder. And
you can even nominate a complete outsider (assuming
he or she would consent of course.)

T+9 On the 9th of February we will send out a list of candidates to
general@.

You then have exactly 48hrs to complain about omissions,
mistakes, etc.

T+9 On the 9th of February we will email out a list of all the
committers eligible to vote to general@, *-dev, members@ and
all commiters individually.

Check that you are on that list.

Otherwise you will not get to have your vote counted.

Your @apache.org address will be used.

T+12Final list of committers eligible to vote compiled
and published to general@.

T+12Final list of candidates compiled and published
to general@.

T+12On the 12th of February we will send each committer and
general@ a ballot form.

The ballot will contain the names of each candidate and the
short description they have provided.

Please return this to us on the address

[EMAIL PROTECTED]

before the 19th of February.

Voting Rules:

- You have seven votes.
- A ballot with no votes is invalid.
- A ballot with more than seven votes in invalid.
- You can only cast one vote per candidate.
- If you do not use all seven votes - the remainder of
  the votes will be counted as abstained.
- Returned ballots which are unreadable are invalid.

Reminder: your vote does not have to be cast in public and
for the truly paranoid - pgp keys for the voting volunteers
mentioned above. Regardless of encryption: your vote will
go on record in the clear with the ASF and ASF records are
subject to the usual provisions for US corpo

JSP -en- masse mapping

[Dirk-Willem van Gulik]

On a site with lots of virtual hosts and .jsp files just about everywhere
on lots of directory levels I was looking for a way to simplify and
clarify the config. (Running tomcat 3.2.1 and mod_jk).

But I've not been able to find in the documentation the right sort of
magic to do something like:

AddHandler  jakarta-script  .jsp

rather than the

JkMount /*.jsp  ajp12
JkMount /Foo/*.jsp  ajp12

'per-directory' looking kina jsp mapping. Is there any way to do this
easily; (I know that the above happens to work) or am I just silly and do
RTFM/source code again ?

Any pointers appreciated.

Dw