-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Luca,
On 4/15/15 5:40 PM, Luca Menegus wrote: > Hi Christopher (and Konstantin), > > took some time to reply as I wanted to test your suggestions: > > - "a parameterized server.xml that pulls the password [...]": If I > understood your hint correctly it boils down to passing secrets as > JVM args (using -D or env vars). I do not think that would satisfy > my use case as it implies passing secrets on command line or > environment. Not acceptable for us. Definitely don't use system properties: those will show up in a ps listing, and would take the problem from already-solved to totally-broke n. My actual suggestion was to use a tool like ant to do deployment-time replacement of a token *in the file* with another value (the password). Something like this: <Connector ... keystorePass="@keystorePassword@" ... /> During deployment, you take /path/to/staged/webapp/conf/tomcat-server.xml and copy-with-filtering into /path/to/actual/tomcat/conf/server.xml. The resulting file has: <Connector ... keystorePass="tiger" ... /> ... or whatever you told Tomcat to do. > - "external XML entities": I gave it a try to this as it looked > really promising; but I couldn't get it working. > > If I got it right your suggestion was I should load the keystore > password from a file by declaring the file as an external entity > in server.xml and then reference it in the keystorePass/keyPass > *attribute* of the relevant Connector entity: (PLS know that my > DTD/XML-fu doesn't seems to be up to the task so I might be > missing something obvious) I looks like loading external entities > as attribute values it's forbidden by design [1] ([2] to know about > the test I made). Put the whole <Connector> in your external entity. Note that I've never bothered trying this, because it just seems like the most work you could do to get the same kind of protection. > *If I'm not wrong* than the only way to do what I'm trying to do is > a patch. If you agree than I'll open an RFE BUG. Let me get you back to your original question. Let me see if I've got this right: Given #1: You have server.xml in revision control. Given #2: You don't want to put a super-secret password into revision control. Conclusion: You must store the super-secret password outside of server.xml. I don't think that's the only conclusion you could have come to. Let me suggest some other possible conclusions, and you tell us if/why each of them is not acceptable. Alt conclusion #1: Use a non-super-secret password. Who cares if "tiger" is in revision-control? Alt conclusion #2: Don't put the password in the <Connector> at all. It will default to "changeit". Use "changeit" as the keystore's passphrase. Alt conclusion #3: "Given #2" is not relevant because the super-secret password doesn't give a reader any access to anything. There is therefore no problem to solve. What do you think? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVL0cNAAoJEBzwKT+lPKRYDEUP/Rb9oSHGT4f/XwAYT08sgWHD y4jXWx0umFK3jzlMssmVM+MHzLlyXGJLFeztK/iT3TuS7kGmQYkwRVOVaTLjPYvq SfhsS3Zvei6JEJwRi35iMRc6kz+YjGomyiuLGd0fF9zGou1BXLGCEbq0+QsGD8+A ZZF//kV+AAmFtEHQRMvCc1DiaNPhDKqbj9OQgoNBM0u4/CVBtbNE+CgNAl4OCUKy wi9Lo8fBTZuNEocsasVGcSdMpxsNV0YKrVdd6hR3Uoc8OxPIdTXv/bHcs5vRaBP1 EJixeIZgQgLh6NYwd/q8WwbOmrBXE3mn/VgLzeQ7imE5RYIYxCe6zJIMM1kNM28Q oKgpS9VotyRyvpLMD7a4Wmltj3tzztErlYQfl46K+ob3lkca0tPeu1mrV6GtkZ1C /ihKd/8rkke6RYYKV/4mRgfBDU4tOeuvobrebkSC7CoRj1DS1WCawO9Aq+Me8BcO m9/FWBKU+yHmjghn2M0lHzVzTKuOWSvJQePIjML4WGuv9xiv+tl16GOnX9RgUWRD SDxzlGK5oHT98Q4D/Cl1mHqfVBUGiCCj39FoR6a9D+SA/k/TLbCutUZtHuM6htYg 0L3ttSmi4EpmLVBLvdFjEXqrQ5neVyyFc7YqbgZZnn45HqwXtlg0MqZiQyZsshso uxnexdws2vN3wF+D4Sxx =tC4S -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
