Jetty, Windows and IdP 3.4

[Rod Widdowson]

> Re: jetty-ssl-context
> 	Per my other note, is there a compatibility limitation preventing is from just combining the truststore and keystore
settings? That
> would suck but it's understandable. We could defer that 4.0.

There are two issues, one painful, the other probably unfixable

The painful one is that if we want to do this with properties the deployer moves from having this

	jetty.sslContext.keyStoreType=PKCS12
	jetty.sslContext.keyStorePassword=My_Special_pass
	jetty.sslContext.keyStorePath=Whatever.p12

to: 

	jetty.sslContext.keyStoreType=PKCS12
	jetty.sslContext.trustStoreType=PKCS12
	jetty.sslContext.keyStorePassword=My_Special_pass
	jetty.sslContext.trustStorePassword=My_Special_pass
	jetty.sslContext.keymanagerPassword=My_Special_pass
	jetty.sslContext.keystoreStorePath=Whatever.p12
	jetty.sslContext.trustStorePath=Whatever.p12

Which is confusing.  Actually I think it sucks that we will even have to document this for the non-windows version, but that’s the
suckiness of Jetty for you.  We could ship our own truststore (which is effectively what the idp.ini which is checked in right now
does) but that seems even more fraught.

The unfixable one is because we have allowed (and, actually, encouraged) absolute pathnames.  I can probably work out how to replace

	jetty.sslContext.keyStorePath=c:\path\to\pkcs12

with 

	jetty.sslContext.keyStorePath=..\..\..\..\path\to\pkcs12.

(and I have tested that that works), but if the keystore was on "d:\" then the deployer is SOL.
 
> Re: jetty-deploy.xml
> 	Same thing really...did we allow the warfile to be placed elsewhere such that we can't just generate idp.xml with the right
path in
> it? 

Well, we have the property so people might have done anything.  Will they have? I would be astounded (particularly for the war path,
the deploy path slightly less so).  But we (wrongly) gave them the option so we have to respect it.

> Even if we did, do we know the path? 
Not sure what you mean.

> If they can't touch idp.xml, which I think is true
Correct.

> I would advise we control that file anyway, and
> it's not that big a deal to generate it, it's not long.

When? I suppose we could do it during install (with pain), or as an add on to the "build" command - somewhere where we can get into
the flow and read the damn property file.  For V4 I have no qualms about ditching this (useless) control point, the only question
being whether we bother to even warn on the old property.  Could we get away with this in 3.4?  I wouldn't like to risk it.

> Anywhere we have to pull in Jetty files is the place we'll run into compatibility bugs on simple Jetty updates because they don't
respect
> their own config in patches.

Absolutely and those three files do worry me.  But I hope that by casting the documentation in terms of "the file differs from the
distributed one by these simple changes" we will avoid shipping breakage.  And the changes *are* simple.

We would probably need to be proactive in watching the (or even the changes) as they happen.  Anybody know how noisy the jetty
repository is?  I'll subscribe to the change stream (I already do this for curl - and a large chunk of windows documentation) and
see what happens

It is the jetty-ssl-context changes that cause me the most angst, but I can live with that for 3.4 (it has been changing about three
times a year).  We can come up with a plan for V4 (possibly a "prepare for upgrade" program).    Jetty-deploy and logging-logback
change even less frequently.

But, going back over my notes for the last week, most of the pain was where things had just been broken on windows; i.e. not because
of semi-reserved files that we changed.   By far the most painful part was finding and fixing the logging-lockback issue and that
only became visible because of the use of conditional imports in spring.  Go figure.  

The pain in jetty-ssl-context was really just a matter of reading and code and re-discovering the changes that we had had to make in
the 9.3 stream.

/R