Am 29.07.2017 um 05:20 schrieb R0b0t1:
Most issues I have seen that arise with submodules come from people
trying to treat the submodule directory in a way that is different
than other objects tracked by Git. If you treat it like a source file
you're tracking most problems should disappear, at least in theory.
Dunno what the problems were for Perl6.
Versioning generated (non-source) files can indeed create problems, but
that's independently of whether it's submodule or not, so don't know what
problem you're seeing here.
No, I meant that I think people were expecting symlink or directory
like behavior from submodules based on the criticism I was reading.
Ah ok.
They behave more like a tracked file and are fairly opaque.
Actually they behave like a directory with *untracked* files.
I wasn't referring to the use of bytecode, but the inclusion of
bytecode blobs in the distribution.
Yeah, I didn't like that myself.
These blobs are there just for bootstrapping, and are supposed to be the
bytecode equivalent of the source code in the nqp tree. So it's not
making stuff opaque, but it's creating a loophole for perpetuating
compilation bugs, and for inserting malicious modifications.
I once reported that but it didn't seem relevant enough to get fixed -
probably because the mere possibility of a problem combined with a lot
of work to fix is less value for effort than all the other things that
aren't up to speed yet.
On the plus side, postponing getting rid of the blobs does not increase
the effort involved, so it can be fixed whenever somebody with enough
time and willingness comes along.
> If there are handwritten pieces
that must remain as blobs then I would hope they are commented.
AFAIK there are not.
Yes and our existing build system is the one we have now. The way to
fix it is gradually by submitting small fixes not talking about
replacing it by your pet build system.
If you think Git is my pet project I am afraid you have mistaken me
for Linux Torvalds.
git is not a build system.
Security is desirable but not currently a main objective of this
project which is more about creating a reasonably fast and very
expressive computer language. If your main interest is security then
you might be better off with a project like OpenBSD and helping update
their Rakudo ports. MoarVM has problems with their W^X system if you
run certain of the roast tests which needs investigation.
Security is something that needs to be designed in from the start,
otherwise it can be almost impossible to accomplish.
Fortunately, binary blobs are not a problem of that kind, nor is
changing the build system.
It's more a social issue because you need consensus, but once consensus
is there, it's not one of the typical "you can't retrofit security"
issues but merely a "it's always been a lot of work but it can still be
done" issue.
E.g. for the binary blobs, Steve Mynott reported that he wasn't
successful recreating the blobs in the way they were originally made,
but I can still imagine that it should be possible to write an NQP
interpreter in Perl5. With that, you can bootstrap the NQP interpreter
written in NQP without needing non-reviewable binary blobs.
Another approach would be to write a bytecode disassembler, just so that
the bytecode becomes reviewable.
Similar considerations apply to the build system. It's essentially a set
of makefiles that run various Perl5 tools and git commands - which is
actually appropriate for a project like Perl6 which assumes that
everybody knows Perl5.
Like with all large codebases, there's always a lot of details that can
be improved. Sometimes it's as easy as regularizing a makefile so it
becomes more readable, sometimes it's architectural changes to make
tools interoperate better.
I agree with Steve that it's going to be more useful to understand how
things are working, and proposing improvements, rather than make
sweeping statements about general principles without sending patches.
The reliance on W^X violating behavior is something I would like to
see removed,
That behaviour does not exist. The binary blobs aren't created as part
of the normal build process, and even if they were, the code writes the
bytecodes to disk, it does not directly execute them.
I can say with no small amount of surety that if an OpenBSD developer
ever read what you just had to say about security they would laugh in
your face and call you an ignorant boob.
Please try to separate what I am saying from any personal attack. I
use strong language to indicate how severely misinformed you are.
Actually that *is* a personal attack. You are hypothesizing about a
ridiculing reaction from somebody you don't even know personally (the
hypothetical OpenBSD developer you're talking about), and saying
"severely misinformed" is one of the strongest insults you can fling at
somebody in a technical group.
On another note, I am please that I remind you of an OpenBSD
developer,
Well, that's just your imagination.
To me, you made a *very* different impression - somebody who knows all
the theory but has not yet taken the time to get deep enough into *any*
security project to be able to make qualified statements.
I.e. you know just enough to be dangerous, but you don't know how to
really cope with the danger. Hopefully, that's a state of mind that will
change, but you really need to get down to actually doing work before
you're able to make constructive proposals.
I am wishing you all the best; other than that, I'm following Steve's
stance of "this is going into diminishing returns".
Which I assume is just a very polite way of describing some pretty
unfriendly reactions to the insults and (in parts) arrogance you have
been showing. Which I take to be unintentional, but that's how you came
across so it's what people's gut reactions are.
HTH
Jo
(back to lurking)
