On 2023/06/27 14:44:46 Christopher Schultz wrote: > Michael, > > On 6/27/23 10:37, Michael Osipov wrote: > > On 2023/06/27 14:13:37 Christopher Schultz wrote: > >> Michael, > >> > >> On 6/27/23 04:06, Michael Osipov wrote: > >>> Chris, > >>> > >>> On 2023/06/26 19:50:39 Christopher Schultz wrote: > >>>> Michael, > >>>> On 6/26/23 13:11, micha...@apache.org wrote: > >>>>> This is an automated email from the ASF dual-hosted git repository. > >>>>> > >>>>> michaelo pushed a commit to branch 1.2.x > >>>>> in repository https://gitbox.apache.org/repos/asf/tomcat-native.git > >>>>> > >>>>> > >>>>> The following commit(s) were added to refs/heads/1.2.x by this push: > >>>>> new 8049561c8 Align default pass phrase prompt with HTTPd > >>>>> 8049561c8 is described below > >>>>> > >>>>> commit 8049561c86c3270b86dfd484fd07f1e8627d6b41 > >>>>> Author: Michael Osipov <micha...@apache.org> > >>>>> AuthorDate: Mon Jun 26 18:05:40 2023 +0200 > >>>>> > >>>>> Align default pass phrase prompt with HTTPd > >>>> > >>>> I'm close to a -1 on this, ant it entirely comes down to something > >>>> stupid that people should definitely NOT do, but they probably actually > >>>> do: script the injection of a password into the startup process because > >>>> #securityReasons and their startup process looks specifically for the > >>>> text "Enter password". > >>>> > >>>> Think expect(1) or similar being used to enter a password automatically > >>>> when, really, the password should not be required for an automated > >>>> process. > >>>> > >>>> I think I'm okay with changing this for 2.x but 1.x is just too set in > >>>> its ways at this point. > >>> > >>> I think you are misunderstanding something here. There is no functional > >>> change. The pass phrase popup has always been there. All I did is to > >>> align the message prompt, nothing else. If you want a decent solution one > >>> needs to port the SSLPassPhraseDialog from mod_ssl. I took a look, a lot > >>> of work, mostly not work the pain. The pass phrase prompt is only > >>> relevant when you start interactively from the terminal, if your process > >>> starts detached, it won't work anyway. I have tried here on HP-UX and > >>> FreeBSD, both failed because stdin is not connected to a tty. > >>> > >>> Can you re-explain your position based on these, new facts? > >> > >> No new facts, here, and I totally understand what you have done: change > >> the text "only". > >> > >> But, expect(1) literally expects specific text. If I have a script that > >> says: > >> > >> === > >> expect "Enter password :" > >> > >> send $password > >> === > >> > >> Then my script stops working because "Enter password :" has changed to > >> "Enter pass phrase:". > >> > >> So after umpteen years, the text is changing and that could break 20 > >> years of scripts written for that specific text. > >> > >> I have not actually tried using expect(1) with this prompt. Does it > >> actually fail? The whole point of expect(1) is to simulate a console and > >> provide input to the process, so I suspect that it will work for the > >> same reasons it's worked for the past 30 years. > >> > >> Did you actually try using expect(1), if did you just "nohup catalina.sh > >> run" or something similar? > > > > I think you have the point here. As written, I tried no-tty option, yes one > > of was nohup. > > Let me try that with py-expect and get back to you tomorrow. I still wonder > > who would actually use that. > > Yes, doing this kind of thing is definitely stupid because if you are > going to put your password into a script, you may as well just put it in > the #&$*% configuration file, but there are still dumb reasons for > things like Tomcat Vault[1] to exist. I just don't want to suddenly > break a bunch of installations for something trivial like the spelling > of an output message.
I did now play around with expect(1), the original one. I can confirm your fears. expect(1) does block when the expected line changes. Question is how big the change is that someone uses which broken setup. Would you accept the compromise that if someone complain we'd roll back in 1.2.x? Michael --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
