On 2023/06/27 18:53:05 Christopher Schultz wrote: > Michael, > > On 6/27/23 12:55, Michael Osipov wrote: > > 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? > > I'd prefer to just not change it. I know that sounds maybe insanely > hesitant and smacks of "nothing can ever change" but this /could/ > represent a very important very breaking change to some users.
If you don't break it you don't know who uses it ;-) > We don't have a policy of "never change anything, never break anything" > but because of the specific interactions in this case, I view the text > of this message almost like a public software interface (i.e. API). > Changing that requires some serious consideration whether the ends > (conformity) justify the means/implications (potential breakage). > > What's the motivation for the change? Just to match httpd? What if nginx > had a different prompt? I know we are more closely-related to httpd, but > it's not like we have to match *either* product. While analyzing code for other reasons I noticed inconsistency and orthographic errors. The author is obvsiously French since he applied French spelling. Anyway, relying on sysout output is always problematic. I don't know whether you can really count this as public API, even undocumented "public". If you really insist, I will revert, no issue. Let me finally know, Michael --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
