>> 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.
