Re: A strong WTF on compiling out plaintext password support by default?!
Den mån 23 aug. 2021 kl 12:15 skrev Johan Corveleyn : > Anyway, concerning package maintainers, for Solaris, I'm getting even > more depressed ... > * We were using Collab.net's distro, but apparently their Solaris > build is no longer maintained: > https://www.collab.net/downloads/subversion > * Wandisco then? Nope: > https://www.wandisco.com/source-code-management/subversion#solaris ... > only Windows, Linux and MacOS. > * Fortunately, there is still a relatively recent build on OpenCSW: > https://www.opencsw.org/packages/subversion/ > > (-> Wandisco's link should be removed from > http://subversion.apache.org/packages.html#solaris -- making that > section empty ... or should we add a link to opencsw then?) > I agree, thanks for the suggestion! How about r1892550 ( http://subversion-staging.apache.org/packages.html#solaris)? Kind regards, Daniel Sahlberg
Re: A strong WTF on compiling out plaintext password support by default?!
Den mån 23 aug. 2021 kl 13:50 skrev Nathan Hartman : > On Mon, Aug 23, 2021 at 6:15 AM Johan Corveleyn wrote: > >> I know the decision to disable plaintext pwd storage by default was >> briefly discussed on this very list [1], but sadly I didn't pay >> attention back then. I have a lot of respect for all people involved >> here, but I think this was a mistake, especially WRT server machines >> which don't have a GUI, no X11 etc. Or even if they have it installed, >> why force additional work on users / sysadmins that have been running >> these machines for years, and now have to jump through additional >> hoops, even if they decided before (through explicit configuration) >> that they were OK with plaintext password storage (= their decision / >> responsability). >> > [...] [1] >> https://lists.apache.org/thread.html/6751582f2d8eda885722933f935a3c90d1b0adb0f9c9dbe536a5c2d7%40%3Cdev.subversion.apache.org%3E >> >> -- >> Johan >> > > > Given the amount of complaints/trouble this change has led to, perhaps we > should rethink it and consider an approach where plaintext saving is always > compiled in but off until enabled by runtime config or something. > Has there been any complaints about Subversion's ability to store passwords in plaintext? (I tried to search the mailing list but didn't come up with anything, possibly because of a lack of imagination on proper keywords). Maybe these complaints would have gone to the different distributions? For reference, here is the e-mail where Stefan Sperling mentions the change in OpenBSD to re-enable support for plaintext passwords in OpenBSD: [2] I would encourage everyone to re-read that message since it has a good summary of arguments (including a link to a request from a corporate security group to TortoiseSVN to avoid storing a password in plaintext in memory). For me the route taken by OpenBSD seems reasonable: - Enable plaintext passwords in the compile time defaults - Disable plaintext passwords in the default runtime configuration - Let the users re-enable it in their configuration if they want to Pros: * It would not change the default behaviour. * It would enable users to enable plaintext passwords in configuration without having to recompile. Cons: * Potentially some security group would argue about the possibility to enable plaintext passwords at all. Kind regards, Daniel Sahlberg [2] http://mail-archives.apache.org/mod_mbox/subversion-dev/202008.mbox/%3C20200807083932.GU55188%40ted.stsp.name%3E
Re: svn commit: r1892471 - in /subversion/trunk/subversion: libsvn_client/conflicts.c libsvn_wc/wc_db.c tests/cmdline/merge_tree_conflict_tests.py
Den mån 23 aug. 2021 kl 11:16 skrev Stefan Sperling :
> On Sat, Aug 21, 2021 at 09:38:56PM +0200, Daniel Sahlberg wrote:
> > > @@ -3028,12 +3028,12 @@ conflict_tree_get_details_local_missing(
> > >
> deleted_basename,
> > >conflict->pool);
> > >details->moves = moves;
> > > + details->wc_move_targets = apr_hash_make(conflict->pool);
> > >if (details->moves != NULL)
> > > {
> > >apr_pool_t *iterpool;
> > >int i;
> > >
> > > - details->wc_move_targets = apr_hash_make(conflict->pool);
> > >iterpool = svn_pool_create(scratch_pool);
> > >for (i = 0; i < details->moves->nelts; i++)
> > > {
> > >
> >
> > I have not investigated further (ENOTIME right now) but I presume some
> > other part of the code expects wc_move_targets to be NULL.
>
> The problem is that some parts of the code try to search the now non-NULL
> hash map with a NULL key because they lack checks for NULL keys.
> I will commit a fix shortly.
>
Thanks!
I can confirm that the test suite now passes.
I'm going to upgrade my vote to +0, not because I have any concerns but
because I don't feel confident enough reviewing the C code to vote +1.
Kind regards,
Daniel Sahlberg
Re: A strong WTF on compiling out plaintext password support by default?!
Johan Corveleyn wrote on Mon, 23 Aug 2021 10:15 +00:00: > So I guess my best shot is contacting the maintainer of the openCSW > package, and asking him to add the --enable-plaintext-password-storage > configure flag and make a new build then. > > Building it ourselves is not an option. Write a wrapper tool that runs svn(1) in a pty and answers password prompts. ASF Infra did this once, complete with the wrapper prompting the user to enter a new password when the old one isn't accepted, but the code isn't public, AFAIK.
Re: A strong WTF on compiling out plaintext password support by default?!
On Mon, Aug 23, 2021 at 1:50 PM Nathan Hartman wrote: > > On Mon, Aug 23, 2021 at 6:15 AM Johan Corveleyn wrote: >> >> On Fri, Aug 7, 2020 at 7:01 AM Robby Zinchak wrote: >> > >> > Small rant here from a very long time subversion user, regarding >> > subversion project's decision to compile out plaintext password storage by >> > default (https://marc.info/?l=subversion-commits&m=154101482302608&w=2). >> > >> > There are a tremendous number of scenarios where users would desire to use >> > subversion without a keyring -- for me, that's today running Ubuntu 20.04 >> > and trying to set up an automated subversion client on a server VM. I >> > obviously can't be logging into a keyring every time the server reboots, >> > that'd be idiotic. >> > >> > I cannot fathom how the team thought this was a good decision. It reeks >> > of devs thinking "we know better, force the users to do it this way," >> > without actually understanding the needs of your users. >> > >> > I'm left with four solutions as far as I can see it: >> > >> > 1) Crowbarring one of the supported keyrings into not needing a keyring >> > password. Assuming this is even possible, it seems like a lot of extra >> > work with no benefit, and added fragility. I am loathe to dive into a >> > whole set of docs to try and figure this out (assuming it's even >> > possible), when the old methods worked just fine. >> > >> > 2) Compiling my own subversion with the enable-plaintext-password-storage >> > flag -- obviously insecure since there's no way I'll be able to keep up >> > with software updates. And I've heard it's quite difficult to compile >> > subversion, so that'll waste precious time I could be spending on >> > something else that's actually productive for my business. >> > >> > 3) Finding an ubuntu package overlay by a third party, questionably >> > insecure since now I have to trust an unofficial/unvetted third party with >> > providing svn builds. >> > >> > 4) Bite the bullet and just switch to another VCS >> > >> > Every time version control comes up in dev conversations among my peers, I >> > go to great lengths to defend SVN against the many criticisms my peers >> > level at it and promote it to other devs looking for a quality VCS. But >> > honestly this decision is one of the most myopic ones I've seen in years >> > on any software project and reeks of the project developers making an >> > idealistic stand that inconveniences users with no practical real-world >> > benefit. The decision should be left to the user, rather than forcing >> > them into a difficult situation. The earlier change to make plaintext >> > something users have to intentionally opt into makes total sense so that >> > users are aware of what they're opting into - but removing it entirely is >> > too far. I guarantee you, right now there are people trying to puzzle >> > through this stack overflow answer, giving up, and switching to git. >> > (https://stackoverflow.com/questions/2899209/how-to-save-password-when-using-subversion-from-the-console) >> > This is a downright awful decision for the overall long term health of >> > what's left of the subversion userbase. >> > >> > I would love to hear what the expected workaround is for users running >> > automated subversion clients on server VMs, because all the options look >> > rather terrible. >> > >> > Thanks for listening to my rant, and be assured it comes only from a place >> > of wanting to see subversion succeed. >> > >> > Best, >> > Robby >> >> Late to te party, but I have to agree with Robby here. I'm only >> running into this now, since we'd like to upgrade the 1.9 client on >> our Solaris build machine to a more recent version ... sigh. >> >> I know the decision to disable plaintext pwd storage by default was >> briefly discussed on this very list [1], but sadly I didn't pay >> attention back then. I have a lot of respect for all people involved >> here, but I think this was a mistake, especially WRT server machines >> which don't have a GUI, no X11 etc. Or even if they have it installed, >> why force additional work on users / sysadmins that have been running >> these machines for years, and now have to jump through additional >> hoops, even if they decided before (through explicit configuration) >> that they were OK with plaintext password storage (= their decision / >> responsability). >> >> I have been defending Subversion at my company for a long time, >> highlighting its stability, simplicity and care for *backwards >> compatibility*. Unfortunately, backwards compatibility is broken here >> (I understand security can trump backwards compatibility, but to me >> this feels more like a "let's make this even more inconvenient" kind >> of security; not plugging a glaring security hole). So there goes one >> of my most important arguments pro SVN :-(. >> >> I know Stefan Sperling suggested in a reply to convince package >> maintainers, if necessary, to re-enable it
Re: A strong WTF on compiling out plaintext password support by default?!
On Mon, Aug 23, 2021 at 6:15 AM Johan Corveleyn wrote: > On Fri, Aug 7, 2020 at 7:01 AM Robby Zinchak > wrote: > > > > Small rant here from a very long time subversion user, regarding > subversion project's decision to compile out plaintext password storage by > default (https://marc.info/?l=subversion-commits&m=154101482302608&w=2). > > > > There are a tremendous number of scenarios where users would desire to > use subversion without a keyring -- for me, that's today running Ubuntu > 20.04 and trying to set up an automated subversion client on a server VM. > I obviously can't be logging into a keyring every time the server reboots, > that'd be idiotic. > > > > I cannot fathom how the team thought this was a good decision. It reeks > of devs thinking "we know better, force the users to do it this way," > without actually understanding the needs of your users. > > > > I'm left with four solutions as far as I can see it: > > > > 1) Crowbarring one of the supported keyrings into not needing a keyring > password. Assuming this is even possible, it seems like a lot of extra > work with no benefit, and added fragility. I am loathe to dive into a > whole set of docs to try and figure this out (assuming it's even possible), > when the old methods worked just fine. > > > > 2) Compiling my own subversion with the > enable-plaintext-password-storage flag -- obviously insecure since there's > no way I'll be able to keep up with software updates. And I've heard it's > quite difficult to compile subversion, so that'll waste precious time I > could be spending on something else that's actually productive for my > business. > > > > 3) Finding an ubuntu package overlay by a third party, questionably > insecure since now I have to trust an unofficial/unvetted third party with > providing svn builds. > > > > 4) Bite the bullet and just switch to another VCS > > > > Every time version control comes up in dev conversations among my peers, > I go to great lengths to defend SVN against the many criticisms my peers > level at it and promote it to other devs looking for a quality VCS. But > honestly this decision is one of the most myopic ones I've seen in years on > any software project and reeks of the project developers making an > idealistic stand that inconveniences users with no practical real-world > benefit. The decision should be left to the user, rather than forcing them > into a difficult situation. The earlier change to make plaintext something > users have to intentionally opt into makes total sense so that users are > aware of what they're opting into - but removing it entirely is too far. I > guarantee you, right now there are people trying to puzzle through this > stack overflow answer, giving up, and switching to git. ( > https://stackoverflow.com/questions/2899209/how-to-save-password-when-using-subversion-from-the-console) > This is a downright awful decision for the overall long term health of > what's left of the subversion userbase. > > > > I would love to hear what the expected workaround is for users running > automated subversion clients on server VMs, because all the options look > rather terrible. > > > > Thanks for listening to my rant, and be assured it comes only from a > place of wanting to see subversion succeed. > > > > Best, > > Robby > > Late to te party, but I have to agree with Robby here. I'm only > running into this now, since we'd like to upgrade the 1.9 client on > our Solaris build machine to a more recent version ... sigh. > > I know the decision to disable plaintext pwd storage by default was > briefly discussed on this very list [1], but sadly I didn't pay > attention back then. I have a lot of respect for all people involved > here, but I think this was a mistake, especially WRT server machines > which don't have a GUI, no X11 etc. Or even if they have it installed, > why force additional work on users / sysadmins that have been running > these machines for years, and now have to jump through additional > hoops, even if they decided before (through explicit configuration) > that they were OK with plaintext password storage (= their decision / > responsability). > > I have been defending Subversion at my company for a long time, > highlighting its stability, simplicity and care for *backwards > compatibility*. Unfortunately, backwards compatibility is broken here > (I understand security can trump backwards compatibility, but to me > this feels more like a "let's make this even more inconvenient" kind > of security; not plugging a glaring security hole). So there goes one > of my most important arguments pro SVN :-(. > > I know Stefan Sperling suggested in a reply to convince package > maintainers, if necessary, to re-enable it with a configure flag (as > he did for OpenBSD). But isn't that world upside down? Should every > packager now explicitly enable it? Why not leave the default as it > was, and tell package maintainers to disable it if they feel sensitive > about this
Re: A strong WTF on compiling out plaintext password support by default?!
On Fri, Aug 7, 2020 at 7:01 AM Robby Zinchak wrote: > > Small rant here from a very long time subversion user, regarding subversion > project's decision to compile out plaintext password storage by default > (https://marc.info/?l=subversion-commits&m=154101482302608&w=2). > > There are a tremendous number of scenarios where users would desire to use > subversion without a keyring -- for me, that's today running Ubuntu 20.04 and > trying to set up an automated subversion client on a server VM. I obviously > can't be logging into a keyring every time the server reboots, that'd be > idiotic. > > I cannot fathom how the team thought this was a good decision. It reeks of > devs thinking "we know better, force the users to do it this way," without > actually understanding the needs of your users. > > I'm left with four solutions as far as I can see it: > > 1) Crowbarring one of the supported keyrings into not needing a keyring > password. Assuming this is even possible, it seems like a lot of extra work > with no benefit, and added fragility. I am loathe to dive into a whole set > of docs to try and figure this out (assuming it's even possible), when the > old methods worked just fine. > > 2) Compiling my own subversion with the enable-plaintext-password-storage > flag -- obviously insecure since there's no way I'll be able to keep up with > software updates. And I've heard it's quite difficult to compile subversion, > so that'll waste precious time I could be spending on something else that's > actually productive for my business. > > 3) Finding an ubuntu package overlay by a third party, questionably insecure > since now I have to trust an unofficial/unvetted third party with providing > svn builds. > > 4) Bite the bullet and just switch to another VCS > > Every time version control comes up in dev conversations among my peers, I go > to great lengths to defend SVN against the many criticisms my peers level at > it and promote it to other devs looking for a quality VCS. But honestly this > decision is one of the most myopic ones I've seen in years on any software > project and reeks of the project developers making an idealistic stand that > inconveniences users with no practical real-world benefit. The decision > should be left to the user, rather than forcing them into a difficult > situation. The earlier change to make plaintext something users have to > intentionally opt into makes total sense so that users are aware of what > they're opting into - but removing it entirely is too far. I guarantee you, > right now there are people trying to puzzle through this stack overflow > answer, giving up, and switching to git. > (https://stackoverflow.com/questions/2899209/how-to-save-password-when-using-subversion-from-the-console) > This is a downright awful decision for the overall long term health of > what's left of the subversion userbase. > > I would love to hear what the expected workaround is for users running > automated subversion clients on server VMs, because all the options look > rather terrible. > > Thanks for listening to my rant, and be assured it comes only from a place of > wanting to see subversion succeed. > > Best, > Robby Late to te party, but I have to agree with Robby here. I'm only running into this now, since we'd like to upgrade the 1.9 client on our Solaris build machine to a more recent version ... sigh. I know the decision to disable plaintext pwd storage by default was briefly discussed on this very list [1], but sadly I didn't pay attention back then. I have a lot of respect for all people involved here, but I think this was a mistake, especially WRT server machines which don't have a GUI, no X11 etc. Or even if they have it installed, why force additional work on users / sysadmins that have been running these machines for years, and now have to jump through additional hoops, even if they decided before (through explicit configuration) that they were OK with plaintext password storage (= their decision / responsability). I have been defending Subversion at my company for a long time, highlighting its stability, simplicity and care for *backwards compatibility*. Unfortunately, backwards compatibility is broken here (I understand security can trump backwards compatibility, but to me this feels more like a "let's make this even more inconvenient" kind of security; not plugging a glaring security hole). So there goes one of my most important arguments pro SVN :-(. I know Stefan Sperling suggested in a reply to convince package maintainers, if necessary, to re-enable it with a configure flag (as he did for OpenBSD). But isn't that world upside down? Should every packager now explicitly enable it? Why not leave the default as it was, and tell package maintainers to disable it if they feel sensitive about this? Anyway, concerning package maintainers, for Solaris, I'm getting even more depressed ... * We were using Collab.net's distro, but
Re: svn commit: r1892471 - in /subversion/trunk/subversion: libsvn_client/conflicts.c libsvn_wc/wc_db.c tests/cmdline/merge_tree_conflict_tests.py
On Sat, Aug 21, 2021 at 09:38:56PM +0200, Daniel Sahlberg wrote:
> > @@ -3028,12 +3028,12 @@ conflict_tree_get_details_local_missing(
> >deleted_basename,
> >conflict->pool);
> >details->moves = moves;
> > + details->wc_move_targets = apr_hash_make(conflict->pool);
> >if (details->moves != NULL)
> > {
> >apr_pool_t *iterpool;
> >int i;
> >
> > - details->wc_move_targets = apr_hash_make(conflict->pool);
> >iterpool = svn_pool_create(scratch_pool);
> >for (i = 0; i < details->moves->nelts; i++)
> > {
> >
>
> I have not investigated further (ENOTIME right now) but I presume some
> other part of the code expects wc_move_targets to be NULL.
The problem is that some parts of the code try to search the now non-NULL
hash map with a NULL key because they lack checks for NULL keys.
I will commit a fix shortly.
