Re: [Monotone-devel] 3rd party libraries
Matthew Nicholson <[EMAIL PROTECTED]> writes: > Zack Weinberg wrote: >> On Thu, Oct 23, 2008 at 3:38 AM, Markus Wanner <[EMAIL PROTECTED]> wrote: >> >>> * lua: pretty similar to sqlite, except the source inclusion variant is >>> a bit more complicated. I'm all for dynamic linking and don't see much >>> of a reason for source inclusion. >> >> I think I mentioned this before, but if we're going to stop bundling >> lua we have to overhaul the error-handling interface between lua and >> our code, because we're currently relying on lua's ability to be >> compiled as C++ and use C++ exceptions to report errors. Of course we >> need to overhaul it *anyway* because right now lots of errors just >> silently get lost, but remember that this is on the critical path for >> unbundling it. > > Yeah, I recently noticed the same issue. To properly unwind the stack > on error in a c++ app, lua needs to be compiled with a c++ compiler. > It uses setjmp and longjmp for error handling when compiled as C and > exceptions when compiled as C++. If we don't require stack unwinding > on error (I have not looked at the code), then dynamic linking is > fine, but I think this is a candidate for bundling. I'm confused. You seem to be implying that a dynamically linked object file cannot be compiled with a C++ compiler. Is that correct? Or is there some limitation on dynamically linked object files, that says they can't propagate exceptions? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Lua loading dynamic libraries not possible in monotone?
On Fri, Oct 24, 2008 at 1:28 PM, Zack Weinberg <[EMAIL PROTECTED]> wrote: > On Fri, Oct 24, 2008 at 1:19 PM, Markus Wanner <[EMAIL PROTECTED]> wrote: >> However, I don't quite understand why it should be a security issue. All >> hooks are user defined, so what should preventing dynamic loading >> protect against? Maybe it's rather a simplification for portability? Zack? > > I honestly don't remember anymore, and I'm not finding any discussion > in the mailing list archive. Maybe Nathaniel remembers? No clue; AFAIK this is the first I've heard about it. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Lua loading dynamic libraries not possible in monotone?
On Fri, Oct 24, 2008 at 1:19 PM, Markus Wanner <[EMAIL PROTECTED]> wrote: > However, I don't quite understand why it should be a security issue. All > hooks are user defined, so what should preventing dynamic loading > protect against? Maybe it's rather a simplification for portability? Zack? I honestly don't remember anymore, and I'm not finding any discussion in the mailing list archive. Maybe Nathaniel remembers? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Lua loading dynamic libraries not possible in monotone?
Hi, Alex Sandro Queiroz e Silva wrote: > Markus Hanauska wrote: >> The platform itself supports this. When downloading and building Lua >> command line interpreter, I can run the code and it works just fine. Yeah, it has been intentionally disabled here: > - > Revision: db3a7b999139a8c005b76b172496e15b276e39db > Ancestor: caaff5d316a3bd5636529a94fd075aba76963583 > Author: [EMAIL PROTECTED] > Date: 2006-08-15T16:08:10 > Branch: net.venge.monotone > > Deleted entries: > m4/popt.m4 > Modified files: > ChangeLog configure.ac lua/luaconf.h m4/boost.m4 options.hh > > ChangeLog: > > * configure.ac: Delete MTN_POPT_DEPENDENCIES. Add strptime to > main AC_CHECK_FUNCS list (this is the only thing that > MTN_POPT_DEPENDENCIES checked for, that was used outside popt). > Also add lrint to this list. Delete AC_SEARCH_LIBS for libdl. > * lua/luaconf.h: Include config.h. Set LUA_USE_POSIX if _WIN32 is > not defined. Add versions of lua_number2int and lua_number2integer > that use the C99 lrint() function; remove the unreliable union hack. > At end of file, forcibly undefine all LUA_DL_* macros to ensure > that lualib.cc uses the stub implementation. > * m4/popt.m4: Delete file. > * m4/boost.m4: Create a new macro to factor out code in common > among most of the MTN_BOOST_LIB_* macros. > * options.hh: Fix typo. > If I remember correctly, it was turned off for security reasons. If that's the case, it's another thing I'd have to check when building monotone against the lua system library, because that one quite certainly has dynamic module loading enabled. However, I don't quite understand why it should be a security issue. All hooks are user defined, so what should preventing dynamic loading protect against? Maybe it's rather a simplification for portability? Zack? @Markus: maybe you want to try my net.venge.monotone.stripped branch, which links against a system provided lua 5.1 library. That one should be capable of loading dynamic libraries. (And I'm curious if you can get nvm.stripped to compile on MacOS X. ;-) ) Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Lua loading dynamic libraries not possible in monotone?
Hallo, Markus Hanauska wrote: > > The platform itself supports this. When downloading and building Lua > command line interpreter, I can run the code and it works just fine. > If I remember correctly, it was turned off for security reasons. -alex http://www.ventonegro.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Lua loading dynamic libraries not possible in monotone?
Hello! Can someone comment on this bug https://savannah.nongnu.org/bugs/?24639 ? What is causing it? Is it a bug or is it by intention? I'd like to create hooks in monotone that need to run native code. The only way to do so is to create a dynamically loadable library, load it from within my Lua script and execute code of it. However, when doing so, monotone Lua says that the support for this feature is missing. Any ideas why? The platform itself supports this. When downloading and building Lua command line interpreter, I can run the code and it works just fine. Kindest regards, Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3rd party libraries
On Fri, Oct 24, 2008 at 1:50 AM, Markus Wanner <[EMAIL PROTECTED]> wrote: >> .. the random number generator... > > Uh.. do we use a RNG from boost as well? We certainly use one from > botan. I'll look into that... some day It might just be for unit tests. If botan can do what we need there, well, less duplication is always good. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3rd party libraries
Hello Jack, Jack Lloyd wrote: > I would really like to get 1.8.0 out the door before the end of the > year. We'll see. Sounds fine to me. Thanks for the overview. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3rd party libraries
[cc'ing botan-devel] On Fri, Oct 24, 2008 at 11:19:21AM +0200, Markus Wanner wrote: > Hi, > > Zack Weinberg wrote: > > I'm all for dynamic linking of botan, too, and being able to use the > > accelerated engines. > > Cool. I'm trying to keep up with the development of botan, test against > new releases and potentially adopt to its changes. I'm eagerly awaiting > 1.8, though. :-) Me too. The major stuff I have on my 1.8 roadmap that would break API at this point is a rewrite/redesign of the libstate/engine code, and splitting the public and private keys up. The engine change is actually something Monotone could benefit from a lot - right now it is pretty difficult (and in some cases downright torturous) to precisely control which implementation of an algorithm Botan is going to use, for instance. But I don't have a really firm idea of what the new design would look like. So this may be deferred. As to the keys - I've realized that deriving the private key classes from the public keys was a mistake. Instead the private key should have an operation public_key() that returns a new public key object. I'd like to fix this sooner rather than later (eg, before 1.8). I may give it a try this weekend, actually. Long run I'd like to redesign/replace Filter/Pipe with something that can handle fine-grained concurrency (with optional thread pool usage, etc) in a clean way. That is a maybe-in-1.9 thing, though. ECC still needs a great deal of profiling and optimization. ECDSA in Botan is orders of magnitude slower than OpenSSL right now. (And also hasn't really even been properly tested against a full set of third-party test vectors). I would really like to get 1.8.0 out the door before the end of the year. We'll see. -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: date certs on net.venge.monotone
Hi, Bruce Stephens wrote: > Because (presumably) it's useful, even though it's not as reliable as > you might like. > > I note that (AFAIK) no other VCS verifies dates either, and they all > still keep them. And emails regularly contain incorrect dates, but > dates are still on the whole useful. Agreed. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: date certs on net.venge.monotone
Markus Wanner <[EMAIL PROTECTED]> writes: [...] > The main motivation is making dates cert information more reliable. But > it looks like that's not considered "core functionality" of monotone. I don't think anyone objects on principle. The question is just of whether it's possible to do that in a cost-effective way. [...] > Why does monotone show a date at all, if it's so unreliable, unchecked > and not considered "core functionality" by monotone? Because (presumably) it's useful, even though it's not as reliable as you might like. I note that (AFAIK) no other VCS verifies dates either, and they all still keep them. And emails regularly contain incorrect dates, but dates are still on the whole useful. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3rd party libraries
Hi, Matthew Nicholson wrote: > I use boost::asio in my astxx library. I have not had any problems with > it, seems well designed. Also there is a non-boost version of it for > the anti boost crowd (I happen to be pro-boost). Thanks for this opinion as well. I'll have a closer look when fiddling with nvm.nuskool again... Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3rd party libraries
Hi, Matthew Nicholson wrote: > Yeah, I recently noticed the same issue. To properly unwind the stack > on error in a c++ app, lua needs to be compiled with a c++ compiler. Hm.. thanks for this hint. > It > uses setjmp and longjmp for error handling when compiled as C and > exceptions when compiled as C++. If we don't require stack unwinding on > error (I have not looked at the code), then dynamic linking is fine, but > I think this is a candidate for bundling. I'll check this issue. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: date certs on net.venge.monotone
Hi, Lapo Luchini wrote: > I think Nathaniel's point of "you can't fix" is important… let's > exemplify it: One can always distrusting invalid information. Currently this involves distrusting the whole revision, but that doesn't necessarily have to be bound together. mtn could easily provide a command to re-certify a revision with a sane date, for example. > day 1. user NTP commits with correct date 2008-10-24 > day 2. user MadTime commits with incorrect date 2009-10-25 >(and you can do nothing about it, as it's incorrect in the future, >so the check you propose would happily pass) > day 3. user NTP tries to commit with correct date 2008-10-26 >gets a warning he can do nothing about as it wasn't his fault really # mtn pull madtime.badhost.com ... WARNING: rev XY is certified to be from the future (or your system's clock is out of sync). ... # date-- checking against wrist-watch # mtn cert XY date `date -u +%Y-%M-%dT%H:%M:%S` Of course, that gets pretty tedious when multiple revisions are involved. But that's a question of good or bad UI, not one of internal workings and checking. And it would require policy branches to be anywhere close to usable. So, yes, at the moment it would involve unwanted UI uglification. So I'm postponing this proposal until we have policy branches :-) Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3rd party libraries
Hi, Zack Weinberg wrote: > I'm all for dynamic linking of botan, too, and being able to use the > accelerated engines. Cool. I'm trying to keep up with the development of botan, test against new releases and potentially adopt to its changes. I'm eagerly awaiting 1.8, though. :-) > So I believe this is the one that started graydon on the "bundle > everything" path, with specific point revs of sqlite 2.x working for > us and others not, and over at my day job we've been having similar > problems with more recent releases of it. So it may well be worth > continuing to bundle a "known good" version of the amalgamation. If > we do, though, we should be much more proactive about testing newer > releases so we don't wind up where we are now (i.e. stuck multiple > feature releases behind the curve) again. Agreed. By now I know about enough to test and integrate new sqlite releases as well. I'll try to keep monotone's sqlite integration code up-to-date as well. I plan to add an optional amalgamation variant to nvm.stripped. > I think I mentioned this before, but if we're going to stop bundling > lua we have to overhaul the error-handling interface between lua and > our code, because we're currently relying on lua's ability to be > compiled as C++ and use C++ exceptions to report errors. Of course we > need to overhaul it *anyway* because right now lots of errors just > silently get lost, but remember that this is on the critical path for > unbundling it. Okay, thanks for the reminder. To be compatible to system libraries, compiling lua with plain C (instead of C++) makes sense, IMO. Thus I'll look into proper lua error handling for C compiled lua. > Regarding file size, are you sure you're not counting debug > information? On my (also 64-bit - amd64) machine, the file is 129KB, > but 'size' says it's only got about 7KB of actual code in it. That's > a n.v.m build; I haven't built your .dates branch but I don't see > anything in there that would bulk it up that much. Oh, right, that was counting debug info as well. It's rather in the order of 11 KiB. > Improved date parsing certainly would be nice to have but I think if > we're going to do anything there, it oughta be that we figure out how > to use gnulib's getdate.y, which is the gold standard as far as > user-supplied date parsing. Okay, thanks for that hint. I won't have time to look into that anytime soon, though. nvm.dates is currently sufficient for my needs WRT dates. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: date certs on net.venge.monotone
Markus Wanner wrote: >> to better provide the functionality of letting people >> know that someone else's clock that they can't fix is broken. > > The main motivation is making dates cert information more reliable. But > it looks like that's not considered "core functionality" of monotone. I think Nathaniel's point of "you can't fix" is important… let's exemplify it: day 1. user NTP commits with correct date 2008-10-24 day 2. user MadTime commits with incorrect date 2009-10-25 (and you can do nothing about it, as it's incorrect in the future, so the check you propose would happily pass) day 3. user NTP tries to commit with correct date 2008-10-26 gets a warning he can do nothing about as it wasn't his fault really Being user NTP I would in fact be bothered by that warning… if we could devise a way to warn user Madtime and not user NTP, I'd happily choose for it, but I can't see a way myself… OK, in my exaggerated +1year case you could use a "are you sure to commit on a 1-year-old branch" warning, but in more mundane +1day cases that wouldn't be nice at all. -- Lapo Luchini - http://lapo.it/ “When two trains approach each other at a crossing, both shall come to a full stop and neither shall start up again until the other has gone.” (Kansas State Legislature) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3rd party libraries
Hi, Zack Weinberg wrote: > In this message I just want to address the boost situation. Thank you very much, that was what I've been looking for: a compilation of reasons for having dropped boost. Makes sense to me. (And justifies that my re-implementation of parts of boost::date_time in our dates.cc wasn't just a waste of time). > .. the random number generator... Uh.. do we use a RNG from boost as well? We certainly use one from botan. I'll look into that... some day > Also, I've read the boost::asio docs and I actually think that would > be a good thing to be using. The abstractions look sane, the author > appears to understand what you need to do to get a stable C++ ABI, and > it would certainly be an improvement over the unmaintained 'netxx' > thing we have now. But I'd much rather we used it in its standalone > "libasio" incarnation, that doesn't pull in any other boost modules. Cool, thanks for this opinion. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL
Brian May wrote: Unfortunately, e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 means nothing to most people. If you added e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 to ~/./monotone///read/-/permissions or /~/./monotone//write-/permissions it means nothing. Just who is allowed access? Maybe you know when you added the entry, but maybe several years later./ If you see e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 signed a certificate, just what does that mean? Nothing. The system I proposed would retain a user name. I proposed that each key have fields for the name, email and a comment. Like this: Daniel Carrera <[EMAIL PROTECTED]> (Foo Inc) e17e2bdd1721ad25f... Monotone could extract this information, even if the file name is e17e2b... I think this system would be an improvement over the current system that simply uses [EMAIL PROTECTED] as the file name. /So you need to identify the user associated with key Depending on what you mean by identify. If you are happy with: Matz <[EMAIL PROTECTED]> (Real name withheld) Then I agree. You don't care what Matz' real name is, as long as you know that this patch was signed by the guy who uses the handle Matz on the list and whom you trust. ///The problem is there is no security in mapping the key to the keyid. If I look at the output of / "ls certs " and see that it was signed by "/[EMAIL PROTECTED]" how do I know it was signed by keyid e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6? I don't. More importantly, how do I know it really was signed by /"/[EMAIL PROTECTED]"? I don't. I understand. The system should (and currently does) do access control based on the keyid (e17e2bdd17...) regardless of what name the key claims to correspond to. If someone uploads e17e2bdd17... to the server and I (evil cracker) make another key (2f0399e...) claiming to be Brian, the server won't trust me. As far as I am aware, there is nothing to stop an attacker changing the mappings in the database, to look like, maybe: If anyone with write access can insert a new trusted key, that is a security hole. But at this point, it doesn't matter if the key says Brian or Dr. Evil. The guy is in. Now everything that was signed by key e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 will look like it was signed by [EMAIL PROTECTED], and everything that appears to be signed by "[EMAIL PROTECTED]" is actually signed by a key that only the attacker was the corresponding private key. What kind of access do you need to mount this attack? This isn't a problem so far - the attacker has only stuffed up his database - however the attacker can trick other people into synchronising from his database... A malicious developer (or an attacker with his credentials) can sync with the server. Would that distribute the change to everyone? If so, that is pretty serious. Ok, so its not quite as smooth as I suggested above; monotone stores the keyid with every certificate, and "mtn log" gets upset when they don't match. This might give the game away. Lets fix that: sqlite> UPDATE revision_certs SET keypair="[EMAIL PROTECTED]" WHERE keypair="[EMAIL PROTECTED]"; Now, "mtn log" is happy and "mtn ls certs " is also happy to display the wrong value: [EMAIL PROTECTED]:~/au.com.microcomaustralia.wiki$ mtn ls certs 1d5a9e4d5f38145d96b4703be7c14bbc9c827a05 And now when you sync to the central server everyone gets the changes too? That's a serious attack. Do some damage and frame another developer (e.g. a co-worker you don't like). To answer the question somebody else asked, note that it would not be sufficient to sign the public key with a trusted GnuPG key. Monotone displays the key was signed by [EMAIL PROTECTED], and [EMAIL PROTECTED] may have a perfectly good GnuPG signature that asserts that the hash 44af5cdd1394964a2adc4de086234c1a76f94a18 belongs to [EMAIL PROTECTED] Yes. The alias (Brian, Matz, Dr Evil) has to be signed as well, alongside the hash. I am going to delete this archive pretty soon just to make sure I don't stuff myself up. So if you want me to run any additional tests on it, better ask soon... I guess we can't ask you to sync with the server :-) But you could setup a local server with a copy of the good database and see what happens when you sync with it. Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] nvm.dates
Hi, I'm considering nvm.dates ready to land on mainline. All it does is using a 64 bit integer to represent dates internally, so that date_t now provides comparison and difference operators on these timestamps. It does not alter the textual representation in the database nor for netsync. As there seems to be a majority voting against further checking of the date cert information, I'm not continuing my efforts into that direction. Instead I've turned that portion of code into an additional "--full" helper option for "mtn db info", which now displays some statistic analysis of those date certs, see below for examples - no warnings, no further checking, only "db info" is affected. I've committed that into a separate branch nvm.dates.statistics. Please review as well, I consider that to be ready to land on mainline, too. Regards Markus Wanner Here's the relevant additional part of "db info --full" for some of the larger monotone databases. Admittedly, the seconds values are often too large to really be human readable, but I'm not overly keen about writing beautification code for that. monotone counts: ancestry edges : 17,827 timestamp correctness between revisions correct dates : 17,733 edges equal dates : 1 edges incorrect dates : 61 edges based on root : 32 edges missing date(s) : 0 edges timestamp differences between revisions: mean: -28,365 sec min : -1,944,060 sec max : 60,951,415 sec 1st percentile : 6 sec 5th percentile : 48 sec 10th percentile : 134 sec 25th percentile : 1,032 sec 50th percentile : 10,026 sec 75th percentile : 72,933 sec 90th percentile : 263,267 sec 95th percentile : 613,691 sec 99th percentile : 3,904,735 sec botan = counts: ancestry edges : 1,797 timestamp correctness between revisions correct dates : 1,793 edges equal dates : 0 edges incorrect dates : 3 edges based on root : 1 edges missing date(s) : 0 edges timestamp differences between revisions: mean: 115,312 sec min : -29,516 sec max : 19,441,763 sec 1st percentile : 9 sec 5th percentile : 24 sec 10th percentile : 43 sec 25th percentile : 160 sec 50th percentile : 736 sec 75th percentile : 6,181 sec 90th percentile : 96,268 sec 95th percentile : 355,795 sec 99th percentile : 2,287,001 sec openembedded counts: ancestry edges : 32,693 timestamp correctness between revisions correct dates : 32,185 edges equal dates : 1 edges incorrect dates : 500 edges based on root : 7 edges missing date(s) : 0 edges timestamp differences between revisions: mean: 24,547 sec min : -49,295,411 sec max : 49,409,456 sec 1st percentile : -6,927 sec 5th percentile : 35 sec 10th percentile : 65 sec 25th percentile : 263 sec 50th percentile : 1,757 sec 75th percentile : 8,855 sec 90th percentile : 39,635 sec 95th percentile : 81,190 sec 99th percentile : 410,294 sec pidgin == counts: ancestry edges : 28,353 timestamp correctness between revisions correct dates : 28,313 edges equal dates : 11 edges incorrect dates : 25 edges based on root : 4 edges missing date(s) : 0 edges timestamp differences between revisions: mean: 52,390 sec min : -10,292,985 sec max : 63,591,821 sec 1st percentile : 14 sec 5th percentile : 62 sec 10th percentile : 129 sec 25th percentile : 583 sec 50th percentile : 3,000 sec 75th percentile : 16,084 sec 90th percentile : 62,077 sec 95th percentile : 116,494 sec 99th percentile : 675,252 sec xaraya == counts: ancestry edges : 23,413 timestamp correctness between revisions correct dates : 17,306 edges equal dates : 5,781 edges incorrect dates : 256 edges based on root : 67 edges missing date(s) : 3 edges timestamp differences between revisions: mean: -88,445 sec min : -80,315,704 sec max : 80,488,504 sec 1st percentile : -345,601 sec 5th percentile : 0 sec 10th percentile : 0 sec 25th percentile : 0 sec 50th percentile : 86,400 sec 75th percentile : 345,601 sec 90th percentile : 1,036,800 sec 95th percentile : 2,335,023 sec 99th percentile : 19,489,817 sec This also solves the mystery of the xaraya repository: I've counted equal dates as invalid before. Obviously they often use some sort of automatic or scripted merge or propagation of revisions, which then end up having equal timestamps. The analysis confirms my assumption that developer machine's clocks are mostly close enough to the commonly known global clock. Percentages of invalid date cert information for the checked repositories are: monotone: 0.34% botan:0.17% oe: 1.53% pidgin: 0.09% xaraya: 1.09% ___ Monotone-devel mailing list Mo
Re: [Monotone-devel] date certs on net.venge.monotone
Hi, Nathaniel Smith wrote: > Make warns about clock skew (between your local host and its NFS > server) because such clock skew breaks Make. Agreed. > Right now, clock skew (between all the hosts used by everyone in a > distributed development project) does not break monotone; This depends on whether you count invalid date certs as breakage or not. You obviously don't, I do. > it continues > to provide its basic functionality of managing revisions just fine. > Your proposal would compromise this core functionality (either by > causing revisions to disappear, or just printing annoying warning > messages), so as to better provide the functionality of letting people > know that someone else's clock that they can't fix is broken. The main motivation is making dates cert information more reliable. But it looks like that's not considered "core functionality" of monotone. > I understand the impulse, Phew, good to hear. > but I don't see how this is the right place > for it -- if I really want to know about clock skew, there are better > ways to find out, and if don't have access to those better ways, I can > just run that script you wrote over my monotone history anyway. My question is: how do I avoid silly situations like this one here: # mtn -d $BOTAN_DB log \ > --brief --last=3 \ > --from 1cc7ac30ff0c2871e24e3a76d147cab907b5429e o 1cc7ac30ff0c2871e24e3a76d147cab907b5429e [EMAIL PROTECTED] | 2006-09-26T19:33:01 net.randombit.botan o fb8114127ac9e23c9870bba631a79c41ece29355 [EMAIL PROTECTED] | 2006-09-27T03:44:57 net.randombit.botan o 3c74c0b06690f73b9d34435e77432e6776c1f7e3 [EMAIL PROTECTED] 2006-09-27T01:29:54 net.randombit.botan Why does monotone show a date at all, if it's so unreliable, unchecked and not considered "core functionality" by monotone? Anyway, I think there's enough resistance to drop the idea for now. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
