jagger11

So, helping Nazi Germany in the beggining of the WW2 seems justified in light of this, I agree.

I don't think I've ever made a point that PL (and earlier PL-LI commonwealth) had a stellar record of treatment of minority nationalities in its borders. Could you clarify with which point I'd made you argue?

Please retract the accussation of lie, it's quite unpleasant to me personally: I said that the title says "march", and you seem to confirm.

It had authoritarianism (with many democratic elements in place) since 1926 (way way more liberal than that of Soviet Union, or Nazi Germany). Before that it was fully democratic (though, chaotic).

As for the conflicts you'd decribed, some of them were conflicts without clear aggressor (e.g. Polish-Czechoslovak conflicts of 1918) typical of those times, some were misdeeds of Polish state (annexation of Vilnus and Czechoslovakian Zaolzie in 1938).

> 2nd Polish republic was established after WW1, so there was no Polish ground

Versailes declaration (FR, UK, IT), with support of Polish statehood - June 1918 / End of WW1 - November, 1918 / 2nd Polish Republic established - November, 1918 / Start of Polish-Sovet war - February, 1919

I've already condemened it.

PS: I like sharp counterarguments, but I guess it cannot go as "P1: We did wrong! P2: What about that time you did wrong?"

Polish government went exile after the Soviets invaded.

PS: In 1919, it was USSR who fought the war on Polish ground, and lost. I don't think you'll find too much material to play moral high ground here.

That's something both Polish and international historians condemn, and there's no serious justification of this act, not in maintream Polish history books, nor on Wikipedia (described as "annexation" in .pl wiki). PS: Poland was not a signatory to the Munich agreements.

Hi,

> I mean, linker tricks à la LD_PRELOAD, DYLD_INSERT_LIBRARIES are a lot less work than rewriting code. They don't even require a recompile most of the time.

Thanks. Also, simply providing static symbols during compilation should work (in most cases), as typically a static linker will only pick up the first provided and referenced (yet undefined) symbol.

Probably even a more "stable" (less conflicting) solution would be to use -Wl,--wrap=symbol and then provide __wrap_symbol() sandboxed definition. Agree, this all doable one way or another, and we might take a look at it at some point (we'll be glad to receive any input on that, preferably on the project's mailing list).

Hi,

Thanks for those ideas - some early comments on those below:

> symbols could just be all prefixed

IMO, this wouldn't be conceptually different from how it works now - i.e. calling function through a C++ object. IOW: code using sandboxing "printf" would have to be changed to use "_sanbdoxed_printf" somehow (via code or linker tricks). Unless you mean something different here?

> File descriptors could be indicated with an annotation or simple function call.

Similarly to the problem above - it's probably in line with how it works now. It can definitely be simplified (even with a simple annotation "somewhere"), but again, that wouldn't probably solve the problem of having drop-in library replacement IMO?

> use a special allocator for anything that's going to be passed to the sandbox, and putting that memory onto an exchange heap ala Singularity.

Yes, that's something we're thinking about, mainly for performance reasons. As you certainly know, it will be more complex than simply having malloc()/calloc() (and friends) operating on a shared mmap(), as memory referenced can also include stack/bss/rodata/direct-mmap etc. etc.

These are all good ideas! Thanks for sharing them - in case you'd like to comment on them more, I'd like to invite you to do that on the project's mailing list.

PS: It might also be here that you might be thinking about something slightly else. I.e. moving all annotations wrt memory/file-descriptors into some middle layer, and then exposing identical-to-the-original library API. This is probably possible, even now, with some extern "C" magic, though there are no examples or tooling on how to do that yet.

Hi, one of the authors here.

The sandboxed library is indeed exec'd (it's a separate binary), so the only "secrets" that leak into it, are those which are already there - compiled into the binary.

As for fork/exec: the idea is to preserve the execution context as long as possible - if data leaks between sequences of library API calls are not a problem (e.g. because we just convert some data for internal use), then forking/execve is not necessary. The idea behind 'transactions' (as per Sandboxed API nomenclature) is just that.

If potential data leaks between API calls might be a problem, then a fresh instance is spawned via fork (no execve is needed here though).