Re: [Monotone-devel] db kill_rev_locally
Daniel Carrera spake unto us the following wisdom: > Thanks. I believe I understand the technique now. Make a dummy account > where all the devs login and give them a shell that does nothing. It's > very good, and it seems to work in every case in which my initial > proposal works. It'd be nice if it was documented on the website > somewhere. It is not documented on the web site simply because this is a standard way to provide a private service. It is by no means specific to monotone, nor is monotone particularly suited to it more than other services. That said, if and when the wiki ever reappears, if you wanted to write up a quick HOWTO I am sure it would be appreciated. Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Ludovic Brenta wrote:
Which would require me to have SSH login ("daniel"). What am I missing?
You are correct but the [EMAIL PROTECTED] account may be
unprivileged (running a restricted shell) and shared with other
developers. You might as well call it after the project the
developers work on, e.g. [EMAIL PROTECTED] The monotone
server itself, and the database, belong to and run as a different
user, e.g. [EMAIL PROTECTED]
Thanks. I believe I understand the technique now. Make a dummy account
where all the devs login and give them a shell that does nothing. It's
very good, and it seems to work in every case in which my initial
proposal works. It'd be nice if it was documented on the website somewhere.
I run a public monotone server on www.ada-france.org; see
http://www.ada-france.org/article131.html for explanations. The
security model is simple: everyone has read access, and only a few
trusted developers have write access to the entire database (they can
create branches at will). Because this is a netsync server running as
a "monotone" user that has /bin/false as its shell, only sysadmins
with root access to the machine can delete from this database.
Thanks. I'll read that article.
Daniel.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Daniel Carrera writes:
> Ethan Blanton wrote:
>> Then, to connect to the server, run something like the following on
>> your workstation:
>>
>> ssh -L4691:localhost:4691
>
> Could you clarify this command? My reading of it is:
>
> ssh -L4691:localhost:4691 [EMAIL PROTECTED]
>
>
> Which would require me to have SSH login ("daniel"). What am I missing?
You are correct but the [EMAIL PROTECTED] account may be
unprivileged (running a restricted shell) and shared with other
developers. You might as well call it after the project the
developers work on, e.g. [EMAIL PROTECTED] The monotone
server itself, and the database, belong to and run as a different
user, e.g. [EMAIL PROTECTED]
I run a public monotone server on www.ada-france.org; see
http://www.ada-france.org/article131.html for explanations. The
security model is simple: everyone has read access, and only a few
trusted developers have write access to the entire database (they can
create branches at will). Because this is a netsync server running as
a "monotone" user that has /bin/false as its shell, only sysadmins
with root access to the machine can delete from this database.
--
Ludovic Brenta.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Ethan Blanton wrote: This requires SSH access to the server in exactly the same manner that running a remote monotone process does. You do not have to give the user access to a general purpose shell; a binary which simply does nothing forever, or sleeps for a period of time and then exits is sufficient. The latter is a decent solution if resources are a concern, because the SSH tunnel will prop open the SSH connection until it is finished, at which point the entire connection will close if the "login shell" has exited. In short, they have only to be able to authenticate, not *do* anything on the remote side. All developers can be given access to the same "account" on the server, with ssh keys granting access only to a dummy shell, or whatever normal precautions you would take. I see now. So the idea is to give them a custom shell that does nothing, but otherwise login through SSH as usual. I get it (I think). Thanks, Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Daniel Carrera spake unto us the following wisdom: >> Then, to connect to the server, run something like the following on >> your workstation: >> >> ssh -L4691:localhost:4691 >> >> This somewhat confusing command line says "Forward port 4691 (the >> leading 4691:) on the local host (-L) to port 4691 on the remote >> machine (localhost:4691)". See 'man ssh' for more on -L (and its >> closely-related cousin, -R). If you used a server port other than >> 4691 for 'mtn serve', replace the *final* 4691 in the above command >> with the port the server is using. > > And allowing this does not require giving developers the ability to SSH > into the server through the terminal? How do you do this? This requires SSH access to the server in exactly the same manner that running a remote monotone process does. You do not have to give the user access to a general purpose shell; a binary which simply does nothing forever, or sleeps for a period of time and then exits is sufficient. The latter is a decent solution if resources are a concern, because the SSH tunnel will prop open the SSH connection until it is finished, at which point the entire connection will close if the "login shell" has exited. In short, they have only to be able to authenticate, not *do* anything on the remote side. All developers can be given access to the same "account" on the server, with ssh keys granting access only to a dummy shell, or whatever normal precautions you would take. Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Ethan Blanton wrote:
Then, to connect to the server, run something like the following on
your workstation:
ssh -L4691:localhost:4691
Could you clarify this command? My reading of it is:
ssh -L4691:localhost:4691 [EMAIL PROTECTED]
Which would require me to have SSH login ("daniel"). What am I missing?
Daniel.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Ethan Blanton wrote: Simply start mtn serve on the hosted server as 'mtn serve localhost:4691' (or whatever port -- any port over 1024 is available to non-root users, 4691 is the default monotone port). This will start a monotone netsync server which can be connected to *only* by processes on the local machine, over loopback. Then, to connect to the server, run something like the following on your workstation: ssh -L4691:localhost:4691 This somewhat confusing command line says "Forward port 4691 (the leading 4691:) on the local host (-L) to port 4691 on the remote machine (localhost:4691)". See 'man ssh' for more on -L (and its closely-related cousin, -R). If you used a server port other than 4691 for 'mtn serve', replace the *final* 4691 in the above command with the port the server is using. And allowing this does not require giving developers the ability to SSH into the server through the terminal? How do you do this? Having done this, on your workstation again, run: mtn sync localhost If you used a port other than 4691 as the first argument to ssh -L, provide it as localhost: in the above command. This will connect to your workstation on a port which SSH tunnels through its own connection to the remote host and connects to the remote monotone server. Interesting. I'm still confuse about whether this requires giving developers SSH login access or not. How can you tunnel through SSH without a login? As far as drawbacks, they are what you would expect; you have to have the SSH tunnel running to access monotone, the encrypted stream is overhead, etc. However, you pay all those penalties to use monotone via SSH in any fashion. Yeah, that's fine. Like you said, it's no worse than the standard SSH solution. Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Daniel Carrera spake unto us the following wisdom: >> If you have to serve through ssh, you'd be much better off starting a >> netsync server somewhere on a localhost port, and tunneling that port >> through ssh. That will take care of both concurrency and your security >> concerns in a much cleaner fashion. > > How do you do that? I'm interested to hear more. What kind of access do > you need to do this? Can you do it if you are an un-privileged user? If > you can, that would be really neat. Are there any drawbacks to your > solution? (e.g. what if the server reboots? can you setup a cron job to > check that the server netsync server is up?). It is possible to restrict the monotone server, but restricting it would break a large number of normal applications, as well. SELinux or similar technologies might be able to effectively restrict it, but I doubt any hosting service that would allow you to install and execute a monotone binary in your hosted space would be using such technologies, or have them configured to prevent this. It is also possible to restrict ssh port forwards, and this may be more likely. I don't have any idea how common such restrictions are. I use no services which restrict port forwards. Simply start mtn serve on the hosted server as 'mtn serve localhost:4691' (or whatever port -- any port over 1024 is available to non-root users, 4691 is the default monotone port). This will start a monotone netsync server which can be connected to *only* by processes on the local machine, over loopback. Then, to connect to the server, run something like the following on your workstation: ssh -L4691:localhost:4691 This somewhat confusing command line says "Forward port 4691 (the leading 4691:) on the local host (-L) to port 4691 on the remote machine (localhost:4691)". See 'man ssh' for more on -L (and its closely-related cousin, -R). If you used a server port other than 4691 for 'mtn serve', replace the *final* 4691 in the above command with the port the server is using. Having done this, on your workstation again, run: mtn sync localhost If you used a port other than 4691 as the first argument to ssh -L, provide it as localhost: in the above command. This will connect to your workstation on a port which SSH tunnels through its own connection to the remote host and connects to the remote monotone server. As far as drawbacks, they are what you would expect; you have to have the SSH tunnel running to access monotone, the encrypted stream is overhead, etc. However, you pay all those penalties to use monotone via SSH in any fashion. Keeping the server running is the same as keeping any server running. There are various scripts out there which will help with that task. Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Ethan Blanton wrote: Yeah, our emails crossed; I didn't realize you were trying to optimize for ssh serving of monotone databases. Serving a monotone database over ssh is not really a solution, it has a number of drawbacks (mostly stemming from the fact that monotone is really Not Very Good at sharing database access). It certainly has drawbacks, but AFAIK it is the only way. If you have to serve through ssh, you'd be much better off starting a netsync server somewhere on a localhost port, and tunneling that port through ssh. That will take care of both concurrency and your security concerns in a much cleaner fashion. How do you do that? I'm interested to hear more. What kind of access do you need to do this? Can you do it if you are an un-privileged user? If you can, that would be really neat. Are there any drawbacks to your solution? (e.g. what if the server reboots? can you setup a cron job to check that the server netsync server is up?). I'm writing an informal paper on Monotone security (following the one from David A. Wheeler). I would like to add a section on how to setup Monotone through SSH to get the optimal security. I would be happy to share this paper if anyone finds it interesting. Cheers, Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Daniel Carrera spake unto us the following wisdom: >> In general, yes, audit trails are great -- but make sure your >> prevention and detection match the threat model you're supposing. > > See my last email. There are standard ways to avoid modification of the > database file through anything but 'mtn'. Yeah, our emails crossed; I didn't realize you were trying to optimize for ssh serving of monotone databases. Serving a monotone database over ssh is not really a solution, it has a number of drawbacks (mostly stemming from the fact that monotone is really Not Very Good at sharing database access). If you have to serve through ssh, you'd be much better off starting a netsync server somewhere on a localhost port, and tunneling that port through ssh. That will take care of both concurrency and your security concerns in a much cleaner fashion. Of course, you can also build a modified monotone binary to simply not offer most of the 'db' commands. Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Jack Lloyd wrote: I would not recommend running Monotone setuid root! For one thing, it is not required. Monotone runs fine as a regular user. You would be far safer running Monotone setuid as some non-privledged user. (In which case what you suggest is a good idea for mediating access through the mtn binary) You are right. Your idea is much better. I am the author of Botan, which is a library used in Monotone. I could not even be sure that Botan is safe to use in a setuid program. It's wise to not run setUID root if you don't have to. And you've shown that Monotone doesn't have to. A secure server would make a custom user just for Monotone, similar to how Apache runs as its own user. That would be a great way to restrict access to the database and ~/.monotone. The problem of malicious insiders is well established and there are a number of known solutions to mitigate the risk. But these solutions fall apart if a program that insiders are supposed to run is insecure. I do think that Monotone's current authorization control system is far too simplistic. Perhaps. But I wanted to suggest only a small easy change in the hopes that it would be more acceptable to developers. I am writing a paper on the security of Monotone. I'm following David A. Wheeler's paper on SCM security: http://www.dwheeler.com/essays/scm-security.html You may be interested to know that Monotone seems to do very well against David's criteria except for the concern over malicious developers or attackers with stolen credentials. If Monotone had a config file where you could disallow certain commands, that would be enough to make it do impressively well against David's criteria. The only feature missing would be support for encrypted branches. But as of today, the presence of "db execute" is a major security gap. Especially because the only way to fix it (deny SSH access) opens a different security gap (trusted paths). If you are interested, I'd be happy to show you the paper when it's one. I expect to finish tomorrow. Best, Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
On Sun, Oct 12, 2008 at 12:01:16AM +0200, Daniel Carrera wrote: > I understand where you are coming from. An attacker with arbitrary shell > access could just run "rm db.mtn". But there are ways to mitigate that > risk. You could give them a custom shell that only allows running one > command: mtn. You can also make db.mtn and ~/.monotonerc belong to root an > run mtn with the set-UID bit like the mount command. I would not recommend running Monotone setuid root! For one thing, it is not required. Monotone runs fine as a regular user. You would be far safer running Monotone setuid as some non-privledged user. (In which case what you suggest is a good idea for mediating access through the mtn binary) I am the author of Botan, which is a library used in Monotone. I could not even be sure that Botan is safe to use in a setuid program. And of course Monotone is much larger than just one library, and interacts with both the filesystem and the network. In general running a program setuid root that is not explicitly written to be setuid is very dangerous - there are a lot of ways to mess up, even if you are being careful (if you haven't seen it, "Setuid Demystified" explains some of the common failures - http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf) > The problem of malicious insiders is well established and there are a > number of known solutions to mitigate the risk. But these solutions fall > apart if a program that insiders are supposed to run is insecure. I do think that Monotone's current authorization control system is far too simplistic. I liked the authentication system Shapiro designed for OpenCM. It was simple, could be very fine grained if required, and was easy to manage project access controls. A design change the Monotone designers call policy branches may or may not fix a lot of the perceived shortcomings of the current model. I know there was an implementation of policy branches going, but I don't know if it was completed. It certainly is not included in normal releases. -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Ethan Blanton wrote: Monotone *cannot* have anything but recovery. If the attacker has write access to your database on the filesystem (which is necessary for thsi attack), he/she can just fire up 'sqlite' and remove as many records as desired. It doesn't matter what monotone wrote or annotated, in that case. In general, yes, audit trails are great -- but make sure your prevention and detection match the threat model you're supposing. See my last email. There are standard ways to avoid modification of the database file through anything but 'mtn'. Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Daniel Carrera spake unto us the following wisdom: > Against this particular attack, Monotone only has recovery. Monotone has > a great recovery system, but something in the way of prevention or > detection would be a worthy improvement. For example: > > 1) Prevention: Remove or somehow restrict the "db kill_rev_locally" > command and the "db execute" command. > > 2) Detection: Record who runs "db kill_rev_locally" (recording "db > execute" is kind of pointless). Monotone *cannot* have anything but recovery. If the attacker has write access to your database on the filesystem (which is necessary for thsi attack), he/she can just fire up 'sqlite' and remove as many records as desired. It doesn't matter what monotone wrote or annotated, in that case. In general, yes, audit trails are great -- but make sure your prevention and detection match the threat model you're supposing. Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Daniel Carosone wrote: This isn't really a security issue, though, because it only affects the database that it's run on. Yes it is, because it easily allows a DOS attack from a malicious developer or someone with a developer's credentials and there is no way to identify the attacker. No. It doesn't require (monotone) credentials (ie, key). It is applicable only to those who have write access (at the OS level) to the developer's database. So it can only happen if the developer has SSH access. Tell me if I'm wrong, but if you want developers to tunnel through SSH they can then execute Monotone commands including "db execute". Right? A malicious developer can only hurt himself, he can't publish something with his key that will kill revs from other users' databases. An attacker with write access to the developer's local db storage can do whatever he likes to that storage, regardless of code we might write in a mtn executable. I understand where you are coming from. An attacker with arbitrary shell access could just run "rm db.mtn". But there are ways to mitigate that risk. You could give them a custom shell that only allows running one command: mtn. You can also make db.mtn and ~/.monotonerc belong to root an run mtn with the set-UID bit like the mount command. The problem of malicious insiders is well established and there are a number of known solutions to mitigate the risk. But these solutions fall apart if a program that insiders are supposed to run is insecure. You could deny SSH access to developers, but that has other security implications that some projects may find unacceptable. Allow me to make a recommendation that I think everyone will find acceptable: Create a mechanism to disable certain commands through a config file. Disable "kill_rev_locally" and "execute" by default. This removes no functionality for users who want to run these commands locally. But an admin on a server can look to protect this file just as he protects the database file. Monotone already depends on ~/.monotone being secure for other purposes, so this does not generally impose an additional requirement on the admin. Developers who want to run these commands locally, can do so easily. Admins who want to secure their server, can do so easily. Everyone's happy. Kind regards, Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
On Sat, Oct 11, 2008 at 11:20:50PM +0200, Daniel Carrera wrote: > Nathaniel Smith wrote: >> No, it simply wipes out the revision and its certs, as if they never >> existed. (Except that as you note, it does leave some of the >> associated data behind in the database, but there's no way to get at >> this data except by poking around in the db by hand.) >> >> This isn't really a security issue, though, because it only affects >> the database that it's run on. > > Yes it is, because it easily allows a DOS attack from a malicious > developer or someone with a developer's credentials and there is no way > to identify the attacker. No. It doesn't require (monotone) credentials (ie, key). It is applicable only to those who have write access (at the OS level) to the developer's database. A malicious developer can only hurt himself, he can't publish something with his key that will kill revs from other users' databases. An attacker with write access to the developer's local db storage can do whatever he likes to that storage, regardless of code we might write in a mtn executable. The attacker can use sqlite directly to manipulate the database, or raw byte manipulation if he wants. > Against this particular attack, Monotone only has recovery. Monotone has > a great recovery system, but something in the way of prevention or > detection would be a worthy improvement. For example: > > 1) Prevention: Remove or somehow restrict the "db kill_rev_locally" > command and the "db execute" command. See above, the attack is outside the scope of this command to prevent. > 2) Detection: Record who runs "db kill_rev_locally" (recording "db > execute" is kind of pointless). And this record could also be removed when manipulating the database directly. The point about recovery is good, though - many other kinds of raw manipulation of the database will be detected as corruption, and not trusted without valid signatures. Destruction of information can only be addressed by replication. -- Dan. pgpNccP6x98Jm.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Nathaniel Smith wrote: No, it simply wipes out the revision and its certs, as if they never existed. (Except that as you note, it does leave some of the associated data behind in the database, but there's no way to get at this data except by poking around in the db by hand.) This isn't really a security issue, though, because it only affects the database that it's run on. Yes it is, because it easily allows a DOS attack from a malicious developer or someone with a developer's credentials and there is no way to identify the attacker. Second, the fact that you can recover from a disaster does not mean that the attack did not succeed. There are three aspects to security against an attack: 1) Prevention. 2) Detection. 3) Recovery. Against this particular attack, Monotone only has recovery. Monotone has a great recovery system, but something in the way of prevention or detection would be a worthy improvement. For example: 1) Prevention: Remove or somehow restrict the "db kill_rev_locally" command and the "db execute" command. 2) Detection: Record who runs "db kill_rev_locally" (recording "db execute" is kind of pointless). Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
On Sat, Oct 11, 2008 at 1:24 PM, Daniel Carrera <[EMAIL PROTECTED]> wrote: > Hello, > > When you run "db kill_rev_locally", does Monotone record who performed that > action? E.g. a malicious developer or an unauthorized person who stole a > developer's credentials might run this command and we would like to know who > it was. No, it simply wipes out the revision and its certs, as if they never existed. (Except that as you note, it does leave some of the associated data behind in the database, but there's no way to get at this data except by poking around in the db by hand.) This isn't really a security issue, though, because it only affects the database that it's run on. If I break into your machine and run kill_rev_locally on some real and important revision, then next time you run 'mtn sync' it will notice that the server has a copy of that revision and your machine does not, and will re-pull it. Nothing is lost. kill_rev_locally only *actually* loses information if the only copy of that information is in the database that the attacker has *direct* access to, and if they have direct access they can remove any record we would like to make anyway. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] db kill_rev_locally
Daniel Carrera wrote: Hello, When you run "db kill_rev_locally", does Monotone record who performed that action? E.g. a malicious developer or an unauthorized person who stole a developer's credentials might run this command and we would like to know who it was. On a related topic: I know that this does not actually delete the revision, but does it delete the *certs* associated with that revision? This is what the documentation says: "It does not actually delete the revision's files or manifest from your database. If you run this command, and then run db check, it will note that you have an “unreferenced manifest”. If you wish to eliminate this data for good (and thus free up the space), you may use netsync to pull from your current database into a new database; this creates a copy of your old database, without the unreferenced data. However, having this data in your database will not cause any problems, and acts as a safety net; if you later realize that you do, after all, need to retrieve the data in id, then db check will let you see which manifest it was, and with some work you can extract id's data." Finally, what is a manifest? ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] db kill_rev_locally
Hello, When you run "db kill_rev_locally", does Monotone record who performed that action? E.g. a malicious developer or an unauthorized person who stole a developer's credentials might run this command and we would like to know who it was. Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
