[Monotone-devel] Re: Testsuite status (SoC)
On Wed, 2006-07-05 at 23:39 -0500, Timothy Brownawell wrote:
> There is minimal documentation in tester.txt and testsuite.txt now,
> currently only having short descriptions of the available functions.
> I've also fixed a problem where the tester couldn't set env vars
> reliably, and a place where a CVS test was being too fast and confusing
> CVS.
>
> There's some oddness with the testsuite on the distcheck buildbots. I'm
> currently trying to get distcheck to run here, then I'll try to track
> this down.
Everything seems to work now, and all the buildbots except win32 (which
has a longstanding unit_tests failure, and what looks like a
canonicalization issue in one of the new tests) are green.
The new testsuite seems to be "done" now, but some things aren't optimal
yet. In particular I'd like to make tester fairly independent from the
rest of monotone by factoring out sanity.{cc,hh} and dependencies into a
libsanity or similar, and by making tester (and libsanity) not depend on
paths.{cc,hh} or the vocab* files (or constants.{cc,hh}).
So far it looks like sanity and dependencies make very minimal use of
these files, so this shouldn't be (much of) a problem. I'll post again
when I have a better idea of exactly how much would need to be changed.
Tim
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: branch review for net.venge.monotone.multihead
On Tue, Jul 11, 2006 at 06:40:54PM -0700, Zack Weinberg wrote: > I was thinking about using commit date as a further heuristic, i.e. > when we have two LCAs neither of which is an ancestor of the other, > merge the newest one first; furthermore, when we have three or more > heads with the same LCA, merge the newest two first. Absent other clearly-obvious better choices (such as conflicting vs non), I like the simple predictability of merging in alpha-sorted revision-id order. In particular, this is important to avoid a lot of merge fan-out. On a busy project with many developers syncing and merging at the same time, all with slightly different mostly-overlapping sets of revisions, we want to minimise the number of additional intermediate merge nodes that will be created because different users will merge subsets of nodes in different orders. Those merge nodes are only going to have to be merged again, creating mostly pointless tangle. As a simple dumb example, consider a minor modification of the present algorithm, that doesn't use any of your additional smarts: 1. make a sorted list of heads 2. attempt to merge the first pair 3. if successful, start again with a new list (that's pretty much what we do now). 4. if not successful, move one slot down the list and try again for the next pair, rather than failing I'm not advocating this change. This is by no means going to produce the best chances for a successful or least-manual-assistance merge, as you're trying to do. To illustrate my point, however, it will do a pretty good job of producing convergent sets of merge nodes amongst multiple people attempting to merge, while allowing further progress than we currently do. Both objectives are important, and you need to consider the tradeoffs between them. I don't have a clear picture of what those tradeoffs might be, but i'm nervous that, between developers with partial views of eachothers work, the nodes that diverge recently from LCAs are perhaps the *least* likely nodes for them to have in common. A counterargument against any more eager merging algorithm is that if such merges are stopped at the first failure, there's another opportunity to sync and learn of more nodes before attempting again. If we merge eagerly in such cases, we're going to produce a more complex set of internal merge nodes and multiple re-merges before finally getting to a single head. I'm not trying to discourage you, nor to suggest that having extra merge nodes is really something to be frightened of: just that we need to consider this too. For all I know, we can come up with a selection order algorithm that will actually improve this situation. One strawman example that comes immediately to mind is to merge nodes with common author certs first, on the assumption an author is more likely to know about their own revisions than those of others. > However, it > seems like a huge pain to get from a revision_id to its commit date, > and in fact I'm not sure the date cert is guaranteed to exist. It's not certain to exist. It's not certain to be correct. It's not certain to be unique. It's not certain to represent time-of-commit; I have at least one case where I set the date according to the time the content was current, rather than the time i'm later committing that record. The most pertinent example here, though, is common merge nodes that have been created by different people; they'll have different dates on them and will be sorted differently by different viewers until the date certs meet up. I don't think it's a good idea. -- Dan. pgpCEkoWDGEYD.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: branch review for net.venge.monotone.multihead
On Wed, 2006-07-12 at 02:51 +0100, Bruce Stephens wrote: > "Zack Weinberg" <[EMAIL PROTECTED]> writes: > > > I was thinking about using commit date as a further heuristic, i.e. > > when we have two LCAs neither of which is an ancestor of the other, > > merge the newest one first; furthermore, when we have three or more > > heads with the same LCA, merge the newest two first. However, it > > seems like a huge pain to get from a revision_id to its commit date, > > and in fact I'm not sure the date cert is guaranteed to exist. > > I think mtn always creates a date cert. There may be more than one, > of course (with different values), so there's a certain amount of > flexibility in how you might determine the "newest two". It will always generate one, yes. But it's perfectly valid for there not to be one (probably can only happen with 'db execute'), or as Bruce said for there to be more than one. So don't rely on there being a unique date cert, or even there being a date cert at all. Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: branch review for net.venge.monotone.multihead
"Zack Weinberg" <[EMAIL PROTECTED]> writes: > I was thinking about using commit date as a further heuristic, i.e. > when we have two LCAs neither of which is an ancestor of the other, > merge the newest one first; furthermore, when we have three or more > heads with the same LCA, merge the newest two first. However, it > seems like a huge pain to get from a revision_id to its commit date, > and in fact I'm not sure the date cert is guaranteed to exist. I think mtn always creates a date cert. There may be more than one, of course (with different values), so there's a certain amount of flexibility in how you might determine the "newest two". Intuitively it seems like you might try to merge the two "closest" in terms of numbers of files that differ, or something. I've no idea whether that would be a good heuristic, though. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: branch review for net.venge.monotone.multihead
I rewrote CMD(merge) again according to your suggestions; please have a look? I was thinking about using commit date as a further heuristic, i.e. when we have two LCAs neither of which is an ancestor of the other, merge the newest one first; furthermore, when we have three or more heads with the same LCA, merge the newest two first. However, it seems like a huge pain to get from a revision_id to its commit date, and in fact I'm not sure the date cert is guaranteed to exist. Thoughts? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Review of diff-p branch
> Not really pointers, just iterators and a lot of complicated > vector-index arithmetic, but see attached; maybe it's clearer? std::vector iterators are pretty thin wrappers around pointers -- have a lot of the same risks. The patch looks fine; I just feel more warm-and-fuzzy when complicated arithmetic is going on, if the assumptions are also documented in code :-). Looks fine to commit. Done. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Review of diff-p branch
On Tue, Jul 11, 2006 at 02:48:22PM -0700, Zack Weinberg wrote: > On 7/11/06, Nathaniel Smith <[EMAIL PROTECTED]> wrote: > >+/* Find, and write to ENCLOSER, the nearest line before POS which > >matches > >+ ENCLOSER_PATTERN. We remember the last line scanned, and the > >matched, to > >+ avoid duplication of effort. */ > ... > >^^ I think I'd feel more comfortable here with some I()'s scattered > >around here? It is Clever, and involves Pointers, you see. > > Not really pointers, just iterators and a lot of complicated > vector-index arithmetic, but see attached; maybe it's clearer? std::vector iterators are pretty thin wrappers around pointers -- have a lot of the same risks. The patch looks fine; I just feel more warm-and-fuzzy when complicated arithmetic is going on, if the assumptions are also documented in code :-). Looks fine to commit. > ... > >The way the unidiff and context diff writers go back and parse > >their own output seems a bit... well, odd, anyway? > > The requirement is to pass find_encloser() an index which is one less > than the first changed line (+, -, or !) in the hunk; this is not > always a_begin+ctx, as a previous version tried. I could have the > writers keep track of which line this is, but honestly it seemed > clearer to me to do it this way. Fair enough. It's hardly the weirdest bit of code in monotone :-). -- Nathaniel -- "...these, like all words, have single, decontextualized meanings: everyone knows what each of these words means, everyone knows what constitutes an instance of each of their referents. Language is fixed. Meaning is certain. Santa Claus comes down the chimney at midnight on December 24." -- The Language War, Robin Lakoff ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Review of diff-p branch
On 7/11/06, Nathaniel Smith <[EMAIL PROTECTED]> wrote:
+/* Find, and write to ENCLOSER, the nearest line before POS which
matches
+ ENCLOSER_PATTERN. We remember the last line scanned, and the
matched, to
+ avoid duplication of effort. */
...
^^ I think I'd feel more comfortable here with some I()'s scattered
around here? It is Clever, and involves Pointers, you see.
Not really pointers, just iterators and a lot of complicated
vector-index arithmetic, but
see attached; maybe it's clearer?
...
The way the unidiff and context diff writers go back and parse
their own output seems a bit... well, odd, anyway?
The requirement is to pass find_encloser() an index which is one less
than the first changed line (+, -, or !) in the hunk; this is not
always a_begin+ctx, as a previous version tried. I could have the
writers keep track of which line this is, but honestly it seemed
clearer to me to do it this way.
zw
#
# old_revision [573cfc15c40bee71ad016af7f2080a9f31fb533f]
#
# patch "diff_patch.cc"
# from [e804b0182349269a3033a282309e6b65575161da]
#to [1af8e79d1eb7bae50d67f62d6428d093d0f97a43]
#
--- diff_patch.cc e804b0182349269a3033a282309e6b65575161da
+++ diff_patch.cc 1af8e79d1eb7bae50d67f62d6428d093d0f97a43
@@ -775,9 +775,10 @@
boost::scoped_ptr encloser_re;
size_t a_begin, b_begin, a_len, b_len;
long skew;
- ssize_t encloser_last_search;
- ssize_t encloser_last_match;
+ vector::const_reverse_iterator encloser_last_search;
+ vector::const_reverse_iterator encloser_last_match;
+
virtual void flush_hunk(size_t pos) = 0;
virtual void advance_to(size_t newpos) = 0;
virtual void insert_at(size_t b_pos) = 0;
@@ -791,7 +792,7 @@
string const & encloser_pattern)
: a(a), b(b), ctx(ctx), ost(ost), encloser_re(0),
a_begin(0), b_begin(0), a_len(0), b_len(0), skew(0),
- encloser_last_search(0), encloser_last_match(0)
+ encloser_last_match(a.rend()), encloser_last_search(a.rend())
{
if (encloser_pattern != "")
encloser_re.reset(new boost::regex(encloser_pattern));
@@ -807,34 +808,36 @@
{
typedef vector::const_reverse_iterator riter;
+ // Precondition: encloser_last_search <= pos <= a.size().
+ I(pos <= a.size());
+ I(pos >= a.rend() - encloser_last_search);
+
if (!encloser_re)
return;
- riter last = a.rbegin() + (a.size() - encloser_last_search);
- encloser_last_search = pos;
+ riter last = encloser_last_search;
+ riter i= riter(a.begin() + pos);
- for (riter i = a.rbegin() + (a.size() - pos); i != last; i++) {
+ encloser_last_search = i;
+
+ // i is a reverse_iterator, so this loop goes backward through the vector.
+ for (; i != last; i++)
if (boost::regex_search (*i, *encloser_re))
{
-encloser_last_match = a.size() - (i - a.rbegin());
-L(FL("find_encloser: from %u matching line %d, \"%s\"")
- % pos % encloser_last_match % *i);
-
-// the number 40 is chosen to match GNU diff. it could safely be
-// increased up to about 60 without overflowing the standard
-// terminal width.
-encloser = string(" ") + (*i).substr(0, 40);
-return;
+encloser_last_match = i;
+break;
}
- }
- if (encloser_last_match)
-{
- ssize_t i = encloser_last_match;
- L(FL("find_encloser: from %u matching cached %d, \"%s\"")
-% pos % i % a[i]);
- encloser = string(" ") + a[i].substr(0, 40);
-}
+ if (encloser_last_match == a.rend())
+return;
+
+ L(FL("find_encloser: from %u matching %d, \"%s\"")
+% pos % (a.rend() - encloser_last_match) % *encloser_last_match);
+
+ // the number 40 is chosen to match GNU diff. it could safely be
+ // increased up to about 60 without overflowing the standard
+ // terminal width.
+ encloser = string(" ") + (*encloser_last_match).substr(0, 40);
}
void walk_hunk_consumer(vector const & lcs,
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Fixed in NMU of monotone 0.25-0.1
On 7/11/06, Tomas Fasth <[EMAIL PROTECTED]> wrote: Hello Shaun, Regretably I forgot about you for a moment and made an upload of monotone 0.27-1. Please forgive me. Maybe you can do a minor increment to 0.27-2, a new build, and upload with you as maintainer. I'm sorry for causing you extra work. Tomas No worries. Would you be interested in co-maintaining monotone, Tomas? Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] pluck problem
From: Nathaniel Smith <[EMAIL PROTECTED]> Subject: Re: [Monotone-devel] pluck problem Date: Fri, 7 Jul 2006 15:29:28 -0700 > On Fri, Jul 07, 2006 at 03:04:50PM -0400, Craig Lennox wrote: > > It can also already happen through perfectly non-malign means -- a > design goal, actually, was that if two people did the same merge, > they'd usually end up with the same revision, and if they did more > work based off of this merge then there would be no problem. Another > example would be if a patch is sent to a mailing list, and two people > both commit it simultaneously. Thank you very much for the explanation. In fact, the warning from 'db check' generally does NOT present (contrary to my previous description) in cases where two people independently commit the same change, because then the date and changelog fields are likely to differ along with the author field. It does however arise with high certainty in the edge case when someone commits a change then immediately plucks that change to a different branch whose head revision happens to be the original change's parent revision. So, I agree this condition cannot be prevented, but it should be noted in the command reference for the pluck command (whatever it ends up being called). > I think a better solution would be to remove the warnings from 'db > check'. They are sort of nice to have, but they keep scaring people > for no good reason. We added this idea of "serious errors" to 'db > check' to try and make these not-really-errors-just-maybe-interesting > notes less scary, but it hasn't really worked. Perhaps we could leave them in there, but require a switch like --warnings (or --nitpick) to display them? I agree they shouldn't show up in normal usage (as they are quite often not errors serious or otherwise), but it seems a pity to remove them altogether as they could still be useful sometimes. Craig ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] encrypted monotone (and digression on
Jeronimo Pellegrini wrote: On Mon, Jul 10, 2006 at 12:21:46PM -0700, Nathaniel Smith wrote: Well, umm, blame cmarcelo, I guess :-): http://del.icio.us/tag/monotone Ah, right. That's Caio. As a practical matter, I find it unlikely that the FSF will release a GPL v3 that somehow cannot be applied to, say... gnupg. Consult a lawyer etc. etc., but personally I'd just slap "v2 or later" on it and worry about v3... later. Like, after it actually exists :-). I think you're right. I'm a bit of a paranoid when it comes to legal issues, but OK -- GPL v2 it is! You can also take the "or later" clause out and just say v2 specifically. -- Matthew A. Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] "diff -p" default?
Now that we have diff -p support on mainline, is there any reason we
shouldn't make it the default?
(For those who haven't run across this before, diff -p gives output
like:
--- hello 80ad86578e12a12c838cd4ff7ca226aa6bcc44e9
+++ hello 94ebfe438b30bf18631c1846b2891b818f46aa23
@@ -9,3 +9,9 @@ int main()
{
say_hello();
}
+
+void say_goodbye()
+{
+printf("goodbye\n");
+}
+
In particular, note the "int main()" stuck on the end of the @@ line,
to give you context when reading the patch.)
AFAIK it's still compatible with patch(1) and the various other tools
out there.
-- Nathaniel
--
Sentience can be such a burden.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Monotone-devel Digest, Vol 39, Issue 15
On Mon, Jul 10, 2006 at 10:47:35AM -0700, Eric Anderson wrote: Content-Description: message body text > [EMAIL PROTECTED] writes: > > From: Nathaniel Smith <[EMAIL PROTECTED]> > > Subject: Re: [Monotone-devel] Re: Monotone-devel Digest, Vol 39, Issue > >15 > > > > [ code to check that mtn process is still alive after sleep is wrong ] > > I just saw the code in mtn.py that does a sleep(3) in order to wait > for the server to get going. Take a look at the revised attached > patch which does the check and will also bail out quickly if the > sub-process fails. Thanks! I just committed a modified version of this same idea as a3490b231ad2574cb876ee7dcd5e062a8dd0e1d8. -- Nathaniel -- "But in Middle-earth, the distinct accusative case disappeared from the speech of the Noldor (such things happen when you are busy fighting Orcs, Balrogs, and Dragons)." ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] encrypted monotone (and digression on
On Mon, Jul 10, 2006 at 12:21:46PM -0700, Nathaniel Smith wrote: > Well, umm, blame cmarcelo, I guess :-): > http://del.icio.us/tag/monotone Ah, right. That's Caio. > As a practical matter, I find it unlikely that the FSF will release a > GPL v3 that somehow cannot be applied to, say... gnupg. > > Consult a lawyer etc. etc., but personally I'd just slap "v2 or later" > on it and worry about v3... later. Like, after it actually exists > :-). I think you're right. I'm a bit of a paranoid when it comes to legal issues, but OK -- GPL v2 it is! > (In the mean time, a number of people, myself included, will not want > to look at any non-free code, regardless of author's expressed plans.) I never had the intention to make it non-free. It's just that I wasn't OK with that problem (in particular, since the system could be used to encrypt source code, this could be a problem -- but I'll just use teh GPL anyway) > Ah, makes sense -- so it is push/pull only? What do you do to allow > incremental pull? (Or do you? And if not, how does it differ from > gpg --encrypt foo.mtn? ;-)) Actually, it converts your ordinary database to an encrypted one (so you keep both on your desktop/laptop/whatever). When you synchronize, you use the encrypted database. In untrusted hosts you can keep only the encrypted one (the keys won't ever get there, since they're not necessary for syncing). Since the packets are individual files in the encrypted database, when they are synced only the relevant ones are transmitted. I'll work more on that page and on packaging the code later. Right now the site is probably not up to date with the work, and I'm not sure if the mtn server is working there. (Have to work a lot on another project now, can't stop!) J. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Review of diff-p branch
+/* Find, and write to ENCLOSER, the nearest line before POS which
matches
+ ENCLOSER_PATTERN. We remember the last line scanned, and the
matched, to
+ avoid duplication of effort. */
+
+void
+hunk_consumer::find_encloser(size_t pos, string & encloser)
+{
+ typedef vector::const_reverse_iterator riter;
+
+ if (!encloser_re)
+return;
+
+ riter last = a.rbegin() + (a.size() - encloser_last_search);
+ encloser_last_search = pos;
+
+ for (riter i = a.rbegin() + (a.size() - pos); i != last; i++) {
+if (boost::regex_search (*i, *encloser_re))
+ {
+encloser_last_match = a.size() - (i - a.rbegin());
+L(FL("find_encloser: from %u matching line %d, \"%s\"")
+ % pos % encloser_last_match % *i);
+
+// the number 40 is chosen to match GNU diff. it could safely be
+// increased up to about 60 without overflowing the standard
+// terminal width.
+encloser = string(" ") + (*i).substr(0, 40);
+return;
+ }
+ }
+
+ if (encloser_last_match)
+{
+ ssize_t i = encloser_last_match;
+ L(FL("find_encloser: from %u matching cached %d, \"%s\"")
+% pos % i % a[i]);
+ encloser = string(" ") + a[i].substr(0, 40);
+}
+}
^^ I think I'd feel more comfortable here with some I()'s scattered
around here? It is Clever, and involves Pointers, you see.
+for (i = hunk.begin(); i != hunk.end(); i++)
+ if ((*i)[0] != ' ')
+{
+ first_mod = i - hunk.begin();
+ break;
+}
+
+find_encloser(a_begin + first_mod, encloser);
+ost << " @@" << encloser << endl;
^^ The way the unidiff and context diff writers go back and parse
their own output seems a bit... well, odd, anyway?
The docs weren't fully updated when the code changed (and had a
weird formatting issue, with a line starting with a period). I fixed
this.
Merged to mainline.
-- Nathaniel
--
Damn the Solar System. Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better one myself.
-- Lord Jeffrey
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: encrypted monotone (and digression on
On Tue, Jul 11, 2006 at 10:16:18AM +0100, [EMAIL PROTECTED] wrote: > I believe a company called Fortify will allow you to run their security > validation tool (DFA style expert system) against open source code for > free. If I remember properly they found several exploitable issues in the > Kernel. > > Might be worth a look. Well, of course, feel free :-). -- Nathaniel -- - Don't let your informants burn anything. - Don't grow old. - Be good grad students. -- advice of Murray B. Emeneau on the occasion of his 100th birthday ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: encrypted monotone (and digression on
I believe a company called Fortify will allow you to run their security
validation tool (DFA style expert system) against open source code for
free. If I remember properly they found several exploitable issues in the
Kernel.
Might be worth a look.
Joel
> Rob Schoening wrote:
>> I have a somewhat unrelated question that touches on a more fundamental
>> security issue:
>>
>> what is the relative security risk of running netsync on a public port
>> assuming it's running as a non privileged user? how much of a
>> vulnerability is it for the host that's serving it?
>
> Nobody's shown us exploits yet, but it would be foolish for me to imply
> that none exist or are possible. I can point to a few things that might
> reassure you. Whether they do is another matter.
>
> 1. Monotone authenticates users (by RSA-signing a nonce and requesting
> an RSA signature in response) before anything else. One may be able to
> DoS the server (in a CPU sense) if anonymous requests are permitted; if
> you insist on authenticated connections from known clients, this risk is
> reduced.
>
> 2. Monotone does ::read() off a network socket and into a fixed-size
> stack buffer. However, it does this in exactly one place (netsync.cc,
> session::read_some()) and always issues the read call for the full
> length of the buffer, starting at its beginning, and never restarts the
> read or tries to mix parsing and reading.
>
> 3. That buffer is immediately appended to a heap std::string and data is
> parsed from there using "safer" extractor functions. The extractor
> functions all test the length of every extraction against the string
> length, and assert fatally if they are asked to pass the end of the
> string they're reading from. If there's insufficient data for a complete
> command packet during parsing, we give up and restart parsing from the
> string's beginning next time we receive data.
>
> 4. Other major parsing points are basic_io.{cc,hh} and xdelta.cc; it is
> possible that those contain logic that can be tricked into indexing past
> the end of the std::strings they're reading from. I'd be happy to go
> through them with a concerned reader doing an audit / inserting more
> dynamic checks / adding tests that try specific attacks.
>
> 5. With the exception of misbehavior in glibc during getaddrinfo() and
> setlocale(), we appear to be valgrind-clean.
>
> 6. You should be able to chroot / jail / zone / otherwise sandbox us, so
> long as we can access libstdc++, libc, libnss, and our database. We also
> need to be able to create transient journal files in the directory we
> keep the database in, as part of the page-transaction system in sqlite.
>
> Still, it's a nontrivial program, you're right to be concerned. Even if
> you trust our code, we also inherit the possibility of vulnerabilities
> from sqlite, botan, lua, idna, and boost. We do a fair bit of input
> validation, don't call printf, are careful to avoid malloc/free or use
> of raw pointers, etc. but it's hard to be sure.
>
> -graydon
>
>
>
> ___
> Monotone-devel mailing list
> Monotone-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/monotone-devel
>
>
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: encrypted monotone (and digression on
On Mon, Jul 10, 2006 at 05:35:53PM -0700, Graydon Hoare wrote: > 3. That buffer is immediately appended to a heap std::string and data is > parsed from there using "safer" extractor functions. The extractor > functions all test the length of every extraction against the string > length, and assert fatally if they are asked to pass the end of the > string they're reading from. Although an example of careful programming for different objectives, this sounds like a way to DoS/crash a server. The other points all sound good - at least necessary, if not sufficient :-) Another possible interpretation of the question is around data confidentiality, assuming all the other points are addressed. If I expose a monotone server containing a collection of branches, even with all the process containment tricks, I have to rely on monotone's internal security controls regarding selective access to db contents. So it's valid to question the robustness of these controls and any implementation or deployment caveats around them. I'm not really sure if this was part of the OP's concern. -- Dan. pgpo6BObOVMzw.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Fixed in NMU of monotone 0.25-0.1
Hello Shaun, Regretably I forgot about you for a moment and made an upload of monotone 0.27-1. Please forgive me. Maybe you can do a minor increment to 0.27-2, a new build, and upload with you as maintainer. I'm sorry for causing you extra work. Tomas On 21/06/06, Shaun Jackman <[EMAIL PROTECTED]> wrote: On 5/13/06, Tomas Fasth <[EMAIL PROTECTED]> wrote: > I have managed to build and upload the latest version (0.26.0). I use the > pbuilder package and the pdebuild command to do clean environment builds. It > has been an easy task maintaining the monotone package. I have so far not > been trying to do automatic database migration as part of a package upgrade. > I think together with help from the monotone developer community you will be > able to do this in the future. The main programmer Nathaniel and the core > developers around him has been very helpful and understanding. Let me know > when you're ready to adopt. > > Regards, Tomas Hello Tomas, My wrist has healed, and I've packaged monotone 0.27. If you're still happy with my adopting the package, I'm ready to upload. Cheers, Shaun --- monotone-0.27.orig/debian/changelog +++ monotone-0.27/debian/changelog @@ -1,3 +1,11 @@ +monotone (0.27-1) unstable; urgency=low + + * New upstream release. + * New maintainer. + * New watch file. + + -- Shaun Jackman <[EMAIL PROTECTED]> Mon, 19 Jun 2006 09:26:53 -0600 + monotone (0.27-0.1) unstable; urgency=low * New upstream release. --- monotone-0.27.orig/debian/docs +++ monotone-0.27/debian/docs @@ -10,4 +10,3 @@ contrib debian/README.Debian debian/TODO.Debian -examples ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
