Thank you for the contributions related to W^X. In regards to signed releases, well, I can't make Perl 6 developers do anything they don't want to do. I can explain the process or commands or even manage it myself (which would admittedly be a bit strange, having made no other contributions) but if none of those solutions are satisfactory and release signing isn't undertaken then that's it. I think it is reasonable that it hasn't been considered yet. But opposing it, or opposing secure use of Git, is something I would suggest is completely indefensible, especially in a large project.
I very much intend to not clutter the list with drivel, but I think it useful to add responses to some of the latest comments for when the issue of release signing invariably comes up again: On Sat, Jul 29, 2017 at 2:13 AM, Steve Mynott <steve.myn...@gmail.com> wrote: > Submodules *are* already used as I said previously or would be obvious > to anyone reading the code. I'd recommend doing the latter before > posting. > The specific instance where they aren't used is the Star build system, where things are downloaded from a link in what used to be an insecure manner. If I am understanding the explanation this isn't how it's supposed to work but I'm still trying to figure out a way that generates Star from, essentially, a repository full of submodules, because as I understand it R* is just the compiler and a module system. Yes, I will contribute if I think it makes sense to do so. I'm pretty sure I understand what is going on and haven't been able to receive clarification. I don't have any problem being told my question doesn't make sense, but it doesn't seem like that has happened. > Anyway I'm not replying to this thread anymore since it's obvious we > are getting to the point of diminishing returns. > Despite my choice of words I was hoping the presence of a well formed argument would indicate that I was trying to have a discussion. Ignoring what someone has to say because you disagree with them is a great way to culture poorly founded opinions. > An example of what isn't useful is a long self indulgent wordy rant > about how no one else understands security but yourself. Most people > will start ignoring this sort of thing after a while if they haven't > already. > I spent three or four hours researching and putting together all of those replies. I did not do them for my enjoyment, save for that I get from making Perl 6 and its ecosystem more secure. On Sat, Jul 29, 2017 at 3:49 AM, Joachim Durchholz <j...@durchholz.org> wrote: > Am 29.07.2017 um 05:20 schrieb R0b0t1: >> They behave more like a tracked file and are fairly opaque. > > > Actually they behave like a directory with *untracked* files. > Everything in them is untracked in relation to the main repo, but you can specify a tag for the submodule that refers to a point in time for the referenced repository. In a sense the specified tag is like the contents of a file. >> 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. > At the same time, it's not source code and is harder to look at. > 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. > > >>> 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. > True, but it can be used in one. >>> 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. The build system I'm referring to until very recently ran `wget --no-check-certificates`. How is that not a security problem? Moreover the more Git is not used (or used improperly) the less secure the process is, unless signature verification is undertaken for downloaded files in the build script. > 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. > Sadly the major improvement I had to make was in relation to developer behavior. If no one wants to do it then no one will. I tried to support why it should be done (in reply to a specific developer) but that developer did not believe it was a good idea. >> 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. > It is unfortunate that he is wrong, and that in telling him he is wrong I must refer to his person. At a certain point there's no way to make it nice because people generally don't like being told they are wrong. I suggested the proper course of action quite neutrally at first but it was mocked and the argument used poorly supported the conclusion. It is rude to put words into someone else's mouth and I apologize to the OpenBSD developers, as they likely aren't out to make enemies. At the same time most suggestions that increase security are met with justifications for laziness and a refusal to consider safer approaches. >> 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. > Er, why? If you can't really cite any evidence then why do you believe your conclusion? Mean people can be right. Moreover lack of contributions to a security related project doesn't indicate a person doesn't know about the technology involved. Software doesn't exist for software's sake, you're generally supposed to use it for something. > 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. > I don't understand how I've been arrogant. I've put the project's concerns that I may not have considered first in this discussion, and been open to more learned feedback. Mr. Mynott summarily dismissed security and project management techniques because he feels they are irrelevant without supporting his position. The offer to discuss the merits of release signing and authenticated Git commits still stands. R0b0t1.
