> If your main interest is security then > you might be better off with a project like OpenBSD and helping update > their Rakudo ports
Uh… this sounds like we are not welcoming contributions, which is not the case. As clearly pointed out in this thread, there are things that can be improved (even if they bring too little benefit, still). If somebody agrees to put some work into it, then why not? Writing email rants may help, but it's unlikely. I'd love to see a list of things that should be improved (e.g. on rakudo wiki, or maybe a couple of tickets on RT), and proposed solutions for each item. Then perhaps we can start moving into some direction, instead of writing rants here and then replying with rants on how rants are bad. Even if we reject some of these proposals, we'll then have the reasoning for it stored in a structured way instead of having it buried in this horrible thread. TL;DR complain in a useful way by creating tickets or writing plans on how to improve things On Fri, Jul 28, 2017 at 11:57 AM, Steve Mynott <steve.myn...@gmail.com> wrote: > >> On 27 July 2017 at 09:13, R0b0t1 <r03...@gmail.com> wrote: > > > Of course there is still the problem of communicating the release keys > > to someone in the first place, but if the release key is on a public > > keyserver and its ID is referenced on the project site somewhere that > > typically works well enough. > > The main problem is management of the *private keys* and passphrases. > You shouldn't keep private keys on shared servers but secured personal > laptops, which are exactly the sort of systems which suffer data lose > due to a lack of secure backups. > > It's hard enough to create a Rakudo Star release with the present > process (as you yourself have shown) and putting more obstacles in the > way of people to do this by requiring keys isn't progress. I'd rather > see an easier, simpler more robust process. I'd rather see more > people forking the repo and creating their own distros rather than > rubberstamping an official release. Centralised, authorised releases > isn't really in the Perl spirit. > > We can sign tags but if we aren't creating new tags like 2017.07.1 for > NQP and are releasing 2017.07 with known issues this really isn't good > enough. I'd rather use working code which isn't signed than broken > code that is. > > Signing isn't a Magic Security Bullet and coming to Open Source > projects saying "Sign All The Things!" isn't really helpful. > > > What I want is to verify the code I run before I run it. From my > > position the easiest way to do this was to try to grab code from Git. > > The star repository was the only one that looked like it had > > everything in one place and a way to use those things. > > > >>> Are there any signed releases, or do I have to do the equivalent of > curl|sudo? > >> > >> Extracting a tarball and manually running scripts isn't the same as > >> running curl|sudo since you have the chance to read what the scripts > >> do before running them. > >> > >> There is one subsystem where this isn't the case and its left as an > >> exercise for the reader :-) > >> > > > > NQP? I was told that has bytecode in it. If possible I would request > > that this is changed in the future. > > Yes we ship binary blobs to bootstrap. I spent a day trying to > reproduce the current binary blobs and it's not possible. Well maybe > it is possible if you reproduce the exact directory (Windows) > directory structure of the original build system and spoof the system > clock but its an incredibly difficult process and quite frankly a > waste of thing right now since there are more pressing issues like bug > fixing, speed increases and wider adoption of perl 6. > > >> The whole rakudo (and star) build process doesn't fit in well with any > >> third party systems (gentoo, cmake whatever). Having Perl 5 as a > >> dependency for Perl 6 seems to be more reasonable than using anything > >> else. > >> > > > > Why are those things unsuitable? I have used them enough to know that > > they can not solve every problem, but it has eventually become clear > > to me that it is almost always easiest to try to add whatever > > functionality is necessary to an already existing build system than > > trying to manage it myself. > > 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. > > > Please understand that even should I have the time to contribute, I > > still have to read and understand the project. My message is more a > > question of why the build system is the way it is. > > MoarVM is used to build NQP (a subset of Perl 6) which is used to > build Rakudo (Perl 6) > > These sorts of technical issue are not really explainable in emails or > IRC. You actually have to use it to understand it. Start with building > R* from a tarball and then try using the github version to build the > tarball. It's probably easier to understand if you start with 2017.01 > for example since the last two versions used awful hacks with NQP and > MoarVM. You are probably safest using Debian stable (or oldstable). > It will be probably hard and frustrating and not easy. You will > probably end up spending more time on it than you thought. You at > least will end up with more knowledge of the sort of things you are > asking people to spend their free time on. > > 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. >
