mainSavannah Administration - Support: sr #107077, bzr+ssh:// preferable to sftp://

 
 

sr #107077: bzr+ssh:// preferable to sftp://

Submitter:  Robert Millan <robertmh>
Submitted:  Sat 24 Oct 2009 03:30:41 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  In Progress
Privacy:  Public Assigned to:  kfogel
Operating System:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 07 Aug 2011 12:05:35 AM UTC, comment #26: 

This is setup, closing issue.

Michael J. Flickinger <mjflick>
Tue 16 Mar 2010 06:22:26 PM UTC, comment #25: 
Karl Fogel <kfogel>
Tue 09 Mar 2010 09:19:20 PM UTC, comment #24: 

Re-opened, assigned to self, marked as in-progress.  Implementation discussion is in this thread:

http://lists.gnu.org/archive/html/savannah-hackers-public/2010-03/threads.html#00011

Karl Fogel <kfogel>
Wed 03 Mar 2010 10:23:15 PM UTC, comment #23: 

Can this ticket please be re-opened, as all parties seem to agree (based on out-of-band conversations) that bzr+ssh access on Savannah is a desirable thing and not a security risk, and that it's just a question of resources now?

Thanks.

Karl Fogel <kfogel>
Thu 03 Dec 2009 12:23:20 AM UTC, comment #22: 

Also, regarding this:

  • "For example: do you intend, at a point, to implement centralised mail notification on commit? (which is the first thing people ask here) Currently this relies on an expansive, per-repository scanning every 5 minutes through bzr-hookless-email, which isn't scalable."


We are implementing commit notification via a separate script that does not run on savannah.  Stefan Monnier implemented it; I do not know if he used bzr-hookless-email.  But in any case there should not be any "expensive" scan involved.  The way bzr-hookless-email works -- and the way I'd imagine any other reasonable implementation of this would work -- is to remember the last revision for which notification was sent, and then send new notification as new revisions come in.  The cost to savannah is (by definition) no worse than the cost of a developer pulling down the changes since their last pull, which is, of course, one of the most common operations there is in Bazaar.

(It might actually be more efficient to just run bzr-hookless-email on the server side, but either way we're talking about small loads here.  It shouldn't be an issue.)

Karl Fogel <kfogel>
Thu 03 Dec 2009 12:17:00 AM UTC, comment #21: 

On Wed, 2009-12-02 at 23:47 +0000, Sylvain Beucler wrote:
Follow-up Comment #20, sr #107077 (project administration):

>
> "bzr does not permit configuring server side hooks in the repository because
> of security concerns"
>
> But every VCS I know allow this (?).
>
> For example: do you intend, at a point, to implement centralised mail
> notification on commit? (which is the first thing people ask here)
> Currently this relies on an expansive, per-repository scanning every 5
> minutes through bzr-hookless-email, which isn't scalable.


The sysadmins globally install the bzr-email plugin, and then in branch.conf enable it for that branch. Users with write access can:
 - disable it
 - enable it
 - configure it

but thats all.

For a highly secure environment like savannah, I'd be happy to provide an even less configurable bzr-email than normal, which users cannot configure at all beyond choosing to have commits sent or not.

> I expect bzr+ssh to eventually work as a restricted shell that
> will also
> execute repository hooks, and these hooks should be stored in a
> root-restricted directory (like CVS/SVN/Git/Hg).
> (in which case sftp access would be closed to make sure hooks are executed)



We don't have repository hooks (though there is a plugin that enables them). Rather we have plugins, and some plugins look in the repository for configuration. This separation allows sysadmins to select what code may run on the server (install/remove plugins), and users to enable/disable the installed plugins (where those plugins permit being enabled/disabled). Closing sftp to ensure the bzr+ssh server is used is a good idea.

> If you never intend to allow server-side hooks at the repository (!=user)
> level, I guess I can enable bzr+ssh (provided we make sure that homedirs will
> stay read-only), but this sounds strange.
> Currently I'd expect bzr+ssh to eventually run repository hooks.


We have equivalent functionality, but its structured to be safe for users. We have previously discussed having in-branch arbitrary commands and decided against it because its not secure. 'bzr info' of an AFS mounted branch shouldn't be able to rm -rf your homedir (which is a simple example of an attack using the style of hooks some other systems use).

-Rob

Robert Collins <robertc>
Wed 02 Dec 2009 11:47:15 PM UTC, comment #20: 

"bzr does not permit configuring server side hooks in the repository because of security concerns"

But every VCS I know allow this (?).

For example: do you intend, at a point, to implement centralised mail notification on commit? (which is the first thing people ask here)
Currently this relies on an expansive, per-repository scanning every 5 minutes through bzr-hookless-email, which isn't scalable.

I expect bzr+ssh to eventually work as a restricted shell that will also execute repository hooks, and these hooks should be stored in a root-restricted directory (like CVS/SVN/Git/Hg).
(in which case sftp access would be closed to make sure hooks are executed)

If you never intend to allow server-side hooks at the repository (!=user) level, I guess I can enable bzr+ssh (provided we make sure that homedirs will stay read-only), but this sounds strange.
Currently I'd expect bzr+ssh to eventually run repository hooks.

Sylvain Beucler <Beuc>
Wed 02 Dec 2009 04:24:08 AM UTC, comment #19: 

Sylvain et al,

In https://savannah.gnu.org/support/?107077#comment14, Robert Collins (a Bazaar developer) points out that bzr+ssh access does not imply shell access or the ability to run arbitrary hooks.

He also points out that sftp and bzr+ssh interoperate fine.

It is important for the Emacs project to be able to use bzr+ssh, for performance reasons (see Stefan Monnier's comment https://savannah.gnu.org/support/?107077#comment13).

Can savannah please support bzr+ssh?  Is there something we can do (besides Robert's advice) to help with this?

RMS recommended we contact savannah admins about this, in http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg01171.html.

Karl Fogel <kfogel>
Tue 01 Dec 2009 02:50:16 AM UTC, comment #18: 

I didn't meant 'they do not mention sftp', I mean 'they are not related to sftp'.

SFTP is a transport, its use is not implicated in the symptoms you reported.

Whatever the causes were, it wasn't sftp.

Robert Collins <robertc>
Tue 01 Dec 2009 01:36:58 AM UTC, comment #17: 

Those bugs were filed before Nov 7, which is when the second corruption happened.  During that period, we were using mostly bzr+ssh but I can't tell if some of us used sftp at some point.

Our use of bzr-svn in the pre-Nov 7 period (i.e. after the first corruption but before the second) was very limited: I was the only person using it, I used it to sync trunk from SVN to Bazaar, and only in this direction.  Also, it was a recent version of bzr-svn (coupled with a recent version of client-side bzr).

I think this rules out the possibility that bzr-svn originated the second corruption.  This only leaves us with combined bzr+ssh / sftp, and/or repository format.

If it's the bzr+ssh problem you're after, I recommend you look at the most recent messages in https://bugs.launchpad.net/bzr-svn/+bug/462109 .  A complete snapshot of the repository after this second corruption was detected is available (http://download.savannah.gnu.org/releases/grub/robertmh/robertmh/bzr-backup2/)

Robert Millan <robertmh>
Tue 01 Dec 2009 12:17:09 AM UTC, comment #16: 

Robert, those bugs are not related to sftp:// at all.

Robert Collins <robertc>
Mon 30 Nov 2009 04:30:07 PM UTC, comment #15: 

At least the following bugs are related to our trouble with bzr:

https://bugs.launchpad.net/debian/+source/bzr-svn/+bug/462988
https://bugs.launchpad.net/bzr-svn/+bug/462109
https://bugs.launchpad.net/bzr-svn/+bug/462988

I think it's always linked to bzr-svn, and not exclusive to svn pushes but also when only using bzr-svn for pull.

Robert Millan <robertmh>
Sun 29 Nov 2009 09:42:09 PM UTC, comment #14: 

bzr does not permit configuring server side hooks in the repository because of security concerns. If you ensure that ~/.bazaar/plugins is not writable to (or removable) by the uid of the bzr+ssh server, then I'm not aware of any way for a user to add hooks or plugins to a server side process.

Robert; did you file a bug on the corruption you saw? sftp and bzr+ssh interoperate fine under normal circumstances.

Robert Collins <robertc>
Wed 25 Nov 2009 07:24:46 PM UTC, comment #13: 

As Emacs is moving to Bzr, the performance issue of using sftp rather than bzr+ssh is becoming a serious concern.
Read-only access via sftp is usually acceptable, but installing changes via sftp tends to be slow, and since Bzr is already slow when managing Emacs's large history, it makes it that much more painful.

I understand your concern that combining sftp and bzr+ssh amounts to providing shell access (via commit hooks), so I suggest to address this problem by using a tweaked version of Bzr where the commit hooks are disabled: nothing is lost since currently commit hooks aren't supported anyway (since they don't work via sftp).

Actually, if we ever want to allow bzr+ssh, we will most likely need to go through such a situation anyway (because we will want to allow both sftp and bzr+ssh access at the same time during the transition period, and commit-hooks only make sense if all accesses go through bzr+ssh).

The problem of transferring tens of MB over the internet even when committing relatively small changes is serious and makes the use of Bzr on Savannah problematic.  We need to find a solution to it.  After all, GNU Bazaar is supposed to be the revision control of choice for the GNU system.

Stefan Monnier <monnier>
Thu 12 Nov 2009 09:45:09 PM UTC, comment #12: 

Should I file a separate support request for enabling bzr+ssh again? It really does make a very significant difference and I don't want it to be forgotten.

Colin Watson <cjwatson>
Thu 12 Nov 2009 09:35:27 PM UTC, comment #11: 

Thank you!

Robert Millan <robertmh>
Thu 12 Nov 2009 09:28:26 PM UTC, comment #10: 

I thought it was disabled, but it turns out it was enabled temporarily at a point but not disabled since then. This is the case now.

Sylvain Beucler <Beuc>
Thu 12 Nov 2009 08:41:27 PM UTC, comment #9: 

I don't say bzr+ssh is supported, I say it is enabled.  In fact, we've been using it, with disasterous results.  We believe using bzr+ssh is the reason our repository was corrupted, not once but twice!

If you don't want to support bzr+ssh, I'd feel much safer if it was completely disabled, specially taking into account our mailing lists archives contain old mails referencing bzr+ssh URLs and advicing for their use.

Right now my only option is reminding every project member that bzr+ssh should not be used, and taking backups periodically (I take them every hour) just in case somebody used them by mistake.

Robert Millan <robertmh>
Thu 12 Nov 2009 02:37:50 PM UTC, comment #8: 

You say you want Savannah to support bzr+ssh. I answered: not now.

You say that Savannah supports both sftp and ssh. I don't think so, it only supports sftp.

Sylvain Beucler <Beuc>
Thu 12 Nov 2009 12:11:11 PM UTC, comment #7: 

You're currently allowing both sftp: and bzr+ssh: at the same time.

I suggested that bzr+ssh: be disabled for safety reasons.  You cited security reasons in favour of disabling it too.

It seems that we agree, so why are you closing this bug? :-)

Robert Millan <robertmh>
Thu 12 Nov 2009 10:09:02 AM UTC, comment #6: 

At Savannah we do not allow local shell access to make it harder for users to attempt to exploit vulnerabilities before fixes are applied.

Consequently we will not offer both sftp: and bzr+ssh: at the same time, as the combination of both would allow users to run arbitrary commands on the server through commit hooks, in effect getting local access.

At a point we may move to bzr+ssh completely, but this requires moving all the projects at once, and making sure they can create the directory layouts they need through our web interface. Currently, there is not enough incentive, or time, to do so. In particular it seems server-side commit hook'ing is supported, but there are few actual server-side commit hooks.

As for installing the recent 2.0, we'll wait until this is properly support in Debian stable, or possibly Debian backports.

So it is a bit more complicated than just installing a piece of software on our servers.

Sylvain Beucler <Beuc>
Wed 11 Nov 2009 11:37:06 PM UTC, comment #5: 

It would really be far preferable to support bzr+ssh properly; it should just be a matter of installing an up-to-date version of bzr on the server.

bzr is really not at all network-efficient when using sftp, because it tends to have to lock the branch, download the entire pack file, change it, and upload the whole thing again; a trivial commit to grub (which triggered an automatic repack) just involved about 4MB of network transfer for me. bzr+ssh is much, much better for this kind of thing since it can send much more concise messages. The server doesn't usually have to stay religiously in step, but something in the bzr 2.0.x series would be good.

Colin Watson <cjwatson>
Tue 10 Nov 2009 10:24:27 AM UTC, comment #4: 

Does this rule out the possibility of corruption?  We consider it quite likely that bzr+ssh:// is the cause.  Colin?

I'd like to recommend that bzr+ssh:// is entirely disabled untill it is clear that it doesn't corrupt data.  We had repository corruption twice and had to reconstruct the whole repository from scratch both times.  It's a terrible waste of time, sometimes loss of data.  Taking this into account, I think the proposed measure would be reasonable.

Robert Millan <robertmh>
Sat 07 Nov 2009 06:47:16 PM UTC, comment #3: 

Note that Savannah offers sftp-based access to the bzr repository, but do not allow you to run a bzr smartserver of the remote side.

Sylvain Beucler <Beuc>
Sat 07 Nov 2009 03:32:46 PM UTC, comment #2: 

We had some corruption issues with our repository (GRUB project).  We're not sure what caused it yet, but we don't rule out the possibility that it could be related to our use of bzr+ssh://

If I understood correctly, bzr+ssh:// makes us use bzr in daemon mode in the server; this code is otherwise (sftp://) not used, resulting in very different code paths.

Robert Millan <robertmh>
Sat 24 Oct 2009 05:38:45 PM UTC, comment #1: 

I think these warnings are actually a client bug. https://bugs.launchpad.net/bzr/+bug/260335 says that it only happens with a bzr 1.5 client (the version in Debian stable, unfortunately) talking to a 1.6 or later server.

Colin Watson <cjwatson>
Sat 24 Oct 2009 03:30:41 PM UTC, original submission:  


https://savannah.gnu.org/bzr/?group=grub encourages use of sftp:// protocol when branching off a Bazaar repository, but according to Colin Watson (CCed), bzr+ssh:// is a better option.  From his email in grub-devel:

<quote>
I would also generally recommend using bzr+ssh:// rather than sftp://
URLs. sftp:// involves copying all the metadata back and forward for a
number of operations. bzr+ssh:// runs a smart server on the remote
system and interacts with that, which is generally much faster. If you
do this, you'll need to drop /srv/bzr from the URL as well, so:

  bzr branch bzr+ssh://${username}@bzr.sv.gnu.org/grub/trunk
</quote>

However, it appears to generate some warnings.  Perhaps the benefit does not apply untill server is upgraded to 1.2?

$ bzr branch bzr+ssh://robertmh@bzr.sv.gnu.org/grub/trunk
No handlers could be found for logger "bzr"
Server is too old for streaming pull, reconnecting.  (Upgrade the server to Bazaar 1.2 to avoid this)
No handlers could be found for logger "bzr"
Branched 1768 revision(s).
$

Robert Millan <robertmh>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ridikulus_rat
  • -email is unavailable- added by mjflick (Posted a comment)
  • -email is unavailable- added by kfogel (Posted a comment)
  • -email is unavailable- added by robertc (Posted a comment)
  • -email is unavailable- added by monnier (Posted a comment)
  • -email is unavailable- added by Beuc (Posted a comment)
  • -email is unavailable- added by cjwatson (Posted a comment)
  • -email is unavailable- added by robertmh (Submitted the item)
  • -email is unavailable- added by robertmh
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-02-29 ridikulus_rat Carbon-Copy- Added ridikulus_rat
    2011-08-07 mjflick Open/ClosedOpen Closed
    2010-03-09 kfogel StatusNone In Progress
        Assigned toBeuc kfogel
        Open/ClosedClosed Open
    2009-11-12 Beuc Assigned toNone Beuc
        Open/ClosedOpen Closed
    2009-10-24 robertmh Carbon-Copy- Added cjwatson

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code