Am 30.07.2017 um 03:37 schrieb R0b0t1:
> On Sat, Jul 29, 2017 at 3:49 AM, Joachim Durchholz
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
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
I just committed a little change to MoarVM that'll turn off the jit if
we notice we're not allowed to turn a page executable.
https://github.com/MoarVM/MoarVM/commit/b07acdfd92a88d1e40ad42c1c853922b20f1a056
now it won't crash if deny_execmem is turned on. it'll just be slower.
There's appare
On 2017-07-29 18:38, Timo Paulssen wrote:
However, an executable heap is still necessary even though an
executable stack is not needed when MoarVM built to use libffi 3.1 or
later:
This is most likely due to the jit, which allocates a frame, generates
machine code into it, then jumps into it. Ca
Great find on libffi! This ought to be a good way forward for
security-focused distros.
On 30/07/17 00:30, Mark Montague wrote:
> However, an executable heap is still necessary even though an
> executable stack is not needed when MoarVM built to use libffi 3.1 or
> later:
>
> [markmont@f26docker r
On 2017-07-29 08:28, Timo Paulssen wrote:
>> The reliance on W^X violating behavior is something I would like >> to see
removed,
Actually what they are refering to is that dyncall and libffi both
require an executable stack. We can't get around that without making
changes to libffi and dyncall
Am 29.07.2017 um 14:28 schrieb Timo Paulssen:
Actually what they are refering to is that dyncall and libffi both
require an executable stack. We can't get around that without making
changes to libffi and dyncall, sadly.
Ah okay, that was outside the bounds of my knowledge.
And I agree it's u
>> 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.
Ac
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 le
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.
Anyway I'm not replying to this thread anymore since it's obvious we
are getting to the point of diminishing returns.
If you have improvements please s
On Fri, Jul 28, 2017 at 10:20 PM, R0b0t1 wrote:
> Hello,
>
> I apologize for the very long message. Yes, replies to three people
> are in there. The responses were appreciated and I have replied to
> them where replies were warranted.
>
>
> On Fri, Jul 28, 2017 at 2:39 AM, Joachim Durchholz wrote
Hello,
I apologize for the very long message. Yes, replies to three people
are in there. The responses were appreciated and I have replied to
them where replies were warranted.
On Fri, Jul 28, 2017 at 2:39 AM, Joachim Durchholz wrote:
> Am 28.07.2017 um 04:35 schrieb R0b0t1:
>>>
>>> The earlies
On 28 July 2017 at 11:00, Timo Paulssen wrote:
> On 28/07/17 10:57, Steve Mynott wrote:
>> 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)
>> dire
On 28 July 2017 at 11:00, Timo Paulssen wrote:
> On 28/07/17 10:57, Steve Mynott wrote:
>> 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)
>> dire
On 28/07/17 10:57, Steve Mynott wrote:
> 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
> 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
>> On 27 July 2017 at 09:13, R0b0t1 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 ma
Am 28.07.2017 um 04:35 schrieb R0b0t1:
The earliest versions of the Rakudo Star build system started out by trying to
use Git submodules to manage packages, but it quickly proved to be unwieldy and
almost impossible to understand and maintain. Perhaps the submodule ecosystem
has changed since
I apologize if there was any tone to my post, the only place I
intended there to be any was when I pointed out the
--no-check-certificates flag. Please understand Perl 6 is the second
or third language I have found that does not secure its ecosystem. The
number of non-language projects which suffer
Quoting R0b0t1 :
Are there any releases signed by the developers? The official releases
located at https://rakudo.perl6.org/downloads/star/ do not seem to
have signatures available.
There's Rakudo the compiler and Rakudo Star distribution
which is the compiler + docs + some modules.
Yes, the
On 27 July 2017 at 09:13, R0b0t1 wrote:
> Are there any releases signed by the developers? The official releases
> located at https://rakudo.perl6.org/downloads/star/ do not seem to
> have signatures available.
Can you be more specific about the technologies you suggest and the
exact problems you
The details of how to use the star GitHub repository are in
tools/star/release_guide.pod .
You're entirely welcome to create a bundling that has a better build system
than what Rakudo Star uses -- indeed, Rakudo Star has always been intended to
be just one of many possible bundlings of Rakudo a
Are there any releases signed by the developers? The official releases
located at https://rakudo.perl6.org/downloads/star/ do not seem to
have signatures available.
As a stopgap measure I attempted to clone
https://github.com/rakudo/star and run Configure.pl. I felt it strange
that it warned me ag
23 matches
Mail list logo
