Re: [Monotone-devel] Summit thoughts - and changes?
Matthew A. Nicholson wrote: On Fri, Oct 17, 2008 at 11:12:08AM +1100, Daniel Carosone wrote: [...] Discuss. :) -- Dan. I think this is a great idea. Why don't we set a date for the next virtual summit. Perhaps the first full weekend in December (the 5th-7th)? Or is that too close to thanksgiving (US) or christmas? So what about these dates? Or others? -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.dates review
Hi, Markus Wanner wrote: > Agreed, renamed to millisecs_since_unix_epoch(). Hm.. this isn't used anywhere, since date_t::operator-() is sufficient in all cases so far. So we might even drop it. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: nvm.dates review
Hello Zack,
thank you very much for your in-depth review.
Zack Weinberg wrote:
> Under what circumstances would one want a date_t with an invalid value?
The --date option is either given or not. We are parsing dates from
strings pretty often, this might fail or not. And in
nvm.cvsimport-branch-reconstruction, I have a pre-calculated average
date or not, in which case I need to calculate such an average.
All in all, I think you'd more often have to write the following than not:
struct {
bool date_given_and_valid;
date_t the_date_itself;
}
instead of just using date_t as we do now. Also note, that
date_t::valid() has been there before.
>
> + // initialize from a unix timestamp
> + date_t(u64 d);
>
> I am not sure I like having this be a constructor instead of a factory
> function. I don't feel strongly about it, but it was more
> self-documenting the other way. Also, you still have the ::now() and
> ::from_string() factories, so now there's both factories and public
> constructors, which is confusing.
I felt the factory function to be overly verbose. Guess that's a matter
of taste. I didn't change that for now.
> Also, you still have the ::now() and
> ::from_string() factories, so now there's both factories and public
> constructors, which is confusing.
There's the following constructor as well:
> // initialize from multiple values
> date_t(int sec, int min, int hour, int day, int month, int year);
Shall that be converted back to a factory function as well?
> Also, throughout, please make all your comments be complete sentences.
Okay, I'll try.
> + date_t(int sec, int min, int hour, int day, int month, int year);
>
> Why doesn't this take milliseconds as well?
Because we don't really need to initialize with milliseconds anywhere.
Nor does the string output function print them. It was trivial enough to
add it, though, so I just did.
> No "struct", please (same for all the others)
Okay, corrected.
> + void gmtime(struct tm & tm) const;
> + void mktime(struct tm const & tm);
>
> Two problems here: first, you must not use struct tm for internal
> interchange.
Yes, I've had that in mind, but then forgot about it, sorry. That's now
corrected. Including using saner month (1 - 12) and year (1900 is 1900
and not 0) representation.
> Second, as a matter of clarity, please do not give any member function
> (of anything) the same unqualified name as a C library function! I
> was quite confused the first time I read the code.
Hehe, sorry.. well, it took me quite a while to figure out that the
former method "from_unix_epoch" did about the same as "mktime", but
didn't mention it anywhere.
To keep it clear that these methods are about equivalent to the system
functions, I've now prefixed them with "our_". Feel free to rename to
whatever else you find more appropriate, but please keep it clear that
these provide similar functionality.
> +date_t::date_t(int sec, int min, int hour, int day, int month, int year)
> +{
> + // general validity checks
> + I((year >= 1970) && (year <= ));
>
> Here and elsewhere - since you took out the buffer that would be too
> small in CE 1, why are you still restricting the year to <= ?
Because that's been the limit before in date_t::now() and I thought
is far enough in the future for our use.
> The year limit you should enforce is 2147483647, since all system
> structures for broken-down time that I am aware of (i.e. struct tm +
> the several similar things Windows has) use a 32-bit *signed* year
> field. The corresponding seconds-since-1970 count was in the old
> version of the file, although of course it'll need multiplying by
> 1000.
Given that we don't even want to check dates between revisions, I don't
see much point in such general purpose date handling routines. I'll see
if I get around extending the limit anyway, but I'd like doing things
more relevant for monotone again.
> sec <= 60. Leap seconds do happen.
..but we don't support them. Nor did the former (nor current)
"from_string" parsing function.
If we want to add support for leap seconds, that should clearly be done
separately. As long as we don't, I think it's better making sure
our_mktime and our_gmtime are complementary.
> Since your endpoint format is a millisecond count, why do the
> expensive conversion to broken-down time and back? All you need to do
> is calculate and memoize the epoch offset used by this system, and
> then add that value to what you get back from time() and multiply by
> 1000.
We are currently using date_t::now() at exactly one place:
put_standard_certs_from_options(). So this clearly is a micro
optimization. Storing the known_epoch_offset doesn't help much, because
it's barely ever required twice per mtn execution.
However, as you've already written the code, I've added it. Converting
our_mktime to support years below 1970 uncovered a bug therein, so it
was even worth the effort ;-)
> (Since the internal representation is in mi
[Monotone-devel] Re: Can't find lua lib
Hi, Markus Hanauska wrote: > Where does it look for this library? Where do I have to install it? I > downloaded the lib via fink, it is there. I even softlink'ed it to > /usr/lib, still no success. Any ideas? Fink? That sounds like MacOS X, right? Where is it, when you say it's *there*? You might want to try various LUA_CPPFLAGS (or was it LUA_CFLAGS, I don't remember...). 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?
Hi, Markus Hanauska wrote: > Okay, I will try that out. What else is special about this stripped > branch? Any other changes (despite the fact that it uses external lua) > compared to the standard version? It links monotone against the system's libraries, instead of bundling required libraries. You thus need development packages for: PCRE Lua Botan SQLite AFAICR I've already changed the INSTALL document somewhat, please consult that. > Can anyone show a real-life attack for this? After all the Lua code (and > the libraries it might use) have the same restrictions (e.g. file > permissions, other system restriction) as someone would have on command > line anyway. To me a security problem only arises if an attacker could > that way execute code he could otherwise not execute. However Lua will > not be able to access a dynamic library a user isn't able to access > anyway, either by using a stand-alone Lua copy or by compiling a tiny > piece of C code that links against the library and execute it on the > machine. Agreed. 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?
Markus Wanner wrote: @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. ;-) ) Okay, I will try that out. What else is special about this stripped branch? Any other changes (despite the fact that it uses external lua) compared to the standard version? I don't see the security problem so far. Daniel Carosone wrote: > IIRC, the concern was about people running lua code from within > a repository from a malicious committer. Can anyone show a real-life attack for this? After all the Lua code (and the libraries it might use) have the same restrictions (e.g. file permissions, other system restriction) as someone would have on command line anyway. To me a security problem only arises if an attacker could that way execute code he could otherwise not execute. However Lua will not be able to access a dynamic library a user isn't able to access anyway, either by using a stand-alone Lua copy or by compiling a tiny piece of C code that links against the library and execute it on the machine. A case where this can be used to circumvent system restrictions seems rather "constructed" to me. Okay, if I was on a system that forbids any access to external data sources (no USB sticks, no CDs) and also won't allow me downloading anything from the Internet, nor does it offer a C compiler, I may not be able to get a custom executable there to load a certain library and use it (no stand-alone Lua, no own C executable) - in that case I could abuse Lua of montone to make this possible anyway. One might argue how useful such a restricted system is anyway and if a user of it should have access to monotone itself in the first place (since if I can use monotone, I can checkout source containing a custom executable I should not have on this system - smuggling the binary through a monotone repository sync onto the system, checking out and using it). Kindest regards, Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] compilation failure on Win32 MinGW
Hello Stephen, Stephen Leake wrote: > compile on n.v.m Win32 MinGW is failing with: > > ../monotone/botan/es_dev.cpp:7:24: sys/select.h: No such file or directory Hm.. thanks for that report. Must have to do with our self-made build harness for botan and the upgrade to botan 1.7.12 (which already seems old by now). > The problem is in Makefile.am BOTAN_SOURCES; previously, 'es_dev.cpp' > was not included there; it was added if needed in > lib3rdparty_a_SOURCES by an 'if WIN32_PLATFORM' conditional. > > That conditional is still there, and does the same thing. > > So I think we just need to delete 'es_dev.cpp' from BOTAN_SOURCES. That seems correct, thanks. > Hmm. That almost works; now I get the same error in 'es_egd.cpp'. This > was previously not compiled on Win32, but also not on other OS as > well, apparently. It could be added to the same 'if WIN32_PLATFORM' > conditional. That gives no errors on Win32 (obviously). According to the botan module build information, es_egd is only supposed to be built for unix systems. That didn't get clear from your description, but you did keep es_egd.cpp for Unixen in your patch. So did I. > Then I get: > > ../monotone/botan/primes.cpp:608: warning: integer constant is too large for > "long" type > > These constants need a suffix 'LL' to be interpreted as type 'long long'. Yes, this is known an has been discussed with Jack. He didn't want that patched in upstream but instead requires an "-fpermissive" compiler flag. I'm pretty clearly against diverting from upstream, but this currently means compiling all of the 3rd party libraries with "-fpermissive". I'm just wondering why this fails for MinGW. Is your gcc invoked with that flag or not? > See below for the patch for these changes. Any objection to committing > this? I've committed the changes to Makefile.am with minor adjustments and some comments on these exceptions. Thanks for your report and please test again. All in all I'm really looking forward to nvm.stripped to get rid of these "custom build harness" issues. Do you mind test building that branch on MinGW? Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.dates
Hi, Lapo Luchini wrote: > Well the question is: should we allow commits (or rather, imports) to > have a date before year 1970? > (personally I'd use signed for the sake of it, but won't really ever > notice, as I won't be importing anything from the 60s anyway ^_^) We didn't ever support dates before 1970, which is a pretty common boundary. I don't see much reason to add support for that now, either. 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: > So this was not completely clear from the other responses. To help > visualize this, draw an imaginary line between lua code and c++ code > called from lua and monotone's other c++ code. Errors (C++ exceptions) > are not supposed to cross this line. Hm.. that's a good point as well. So we don't only need to pay attention to the lua -> mtn boundary, but also the other way around, when lua calls back mtn. Thanks for that hint. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
