> We are happy to announce the release of GNU Mes 0.26.1.
Great work everyone ^_^
-Jeremiah
> I have apparently become blacklisted there as a reaction to my letter
> pointing out the contentious phrase in the Guix blog.
Nope.
-Jeremiah
> Claims of priority in innovation have some importance to history.
> You can see the level of controversy created by a latecomer who
> claimed that he "invented email" here:
Only if parties care about credit more than seeing the goal reached.
> And there's the key role that priority has in wh
> Wait, fetching those 357 seed bytes and the needed sources from Guix
> repository happens to
> imply some use of external binaries... probably sized at least several
> megabytes? Then what
> was the point with Guix being "first", compared to, as you say, Debian?
It is available in printed for
> Readers of this list should have noticed that source-only verifiable
> bootstrap has been achieved earlier.
> The work presented in [1] provides a full proof of provenance of a verifiable
> Posix-like system with a
> development toolchain, without a reliance on any binary seed.
If your defini
> Now that the core-updates development branch has been merged, the Full-Source
> Bootstrap has come to GNU Guix!
> This means we're building packages from source all the way down. Read all
> about it in this new post:
Great work ^_^
-Jeremiah
> Last I checked, CVE-2007-4559 is still not fixed; and surely not the only
> unfixed (let alone currently unknown)
> such vulnerability that may suddenly become a problem when you switch to a
> scheme where you need to
> unpack an archive before you can verify the authenticity of its contents.
>> Agreed. And I often wish Android had used detached signatures.
>> Though detached signatures would have made distributing APKs more
>> challenging:
>> a single file is much more convenient for end users.
> Sure, but the solution is trivial.
> Create something that you want signed ("item A").
>> It'll solve the reproducible problem but introduce a bootstrapping
>> problem for how those files were generated in the first place.
>FWIW, this seems sorta fine to me.
>As long as a build path exists which _doesn't_ require the PGO AOT snapshot
>info to build successfully.
That is very true,
> It'd be great if other options existed.
> ...
> Thoughts? Does anyone have any better ideas for making PGO reproducible?
Well just having a standard folder with architecture specific sub-folders would
isolate them and
flag them as generated performance information
It'll solve the reproducible
>> The common objection is: "you're building from source but you're not
>> gonna audit all that source code anyway, so why bother?" I think it's
>> akin to security by obscurity. That we collectively can and do fiddle
>> with all this code makes a practical difference; that this is all
>> tra
> I'm not deeply involved in the bootstrappable project but I believe the
> required bootstrap seed in guix is already a lot smaller than the yocto
> projects dependencies (but maybe a few steps are also still missing here).
Depending on if you count the host kernel under 1KB total
https://githu
> Does the GNU Mes bootstrap-reducing team have a plan to replace Grub and the
> Linux kernel and init (and perhaps a BIOS?) with something tiny that runs on
> bare metal and implements a file system, the mount command, and processes?
INIT was the first thing we replaced.
https://github.com/ori
So that everyone is aware, we on the bootstrappable side of the house have
eliminated pregen (Like Bison grammers) files from the GCC bootstrap.
https://github.com/fosslinux/live-bootstrap
Now nothing except human written source should remain
It even makes a pretty graph (
https://github.com/o
> Could you suggest an alternative wording for that section in the report?
> Unfortunately, I don't think I can copy-> paste the text you sent, as it is
> just slightly too technical as it stands.
Then this
https://www.freelists.org/post/bootstrappable/wipfullsourcebootstrap-from-a-357byte-hex0
> Please review the draft for December's Reproducible Builds report:
Minor mistake in regards to mescc-tools-seed
We were informing you that we completed the AArch64 bootstrap to the same level
as the previous knight (on bare metal), x86 and AMD64 bootstraps.
Thus we have 4 independent bootstraps
As we on bootstrappable are terrible at public relations.
I guess I probably should make sure you are aware of our latest work.
AArch64 has been fully bootstrapped to the cross-compiling C level (M2-Planet)
https://github.com/oriansj/mescc-tools-seed
from a minimal hex0 and a minimal kaem shell
> I’ve published a post about the second big reduction of the Guix bootstrap
> binaries
> Thanks to the recent merge of ‘core-updates’ some weeks days ago, the set of
> bootstrap binaries now weighs in at approximately 60 MiB; about 25% of what
> it used to be.
Great job Janneke ^_^
-Jeremiah
>> Why?
>> Even such things as alignment in malloc results in different behavior
>> between x86 and amd64
> If i'm understanding you correctly, this suggests that the results created by
> gtk-update-icon-cache do not belong in any arch-independent package.
> Is this correct?
Partially, as the req
> But it seems odd that the 32-bit architectures would produce
> unreproducible caches when the 64-bit version is reproducible.
Why?
Even such things as alignment in malloc results in different behavior between
x86 and amd64
For example this function is reproducible on AMD64 but not on x86
https:
>> Today I am pleased to announce the following releases:
>> https://savannah.nongnu.org/projects/stage0/
>> https://github.com/oriansj/stage0
>> https://github.com/oriansj/M2-Planet
>> https://github.com/oriansj/mescc-tools-seed
> thanks for sharing these, I've added them to the February report an
> WOW! That is an impressive list. And in 4 hours.
Really ends the debate about how to bootstrap C compilers in my book
> Is there something I can play with on my 32-bit ppc machine to add to the
> list?
Well if you are willing to do some testing it is really trivial to get a new
architecture i
Today I am pleased to announce the following releases:
https://savannah.nongnu.org/projects/stage0/
https://github.com/oriansj/stage0
In stage0 we have gained hand written (in assembly) C compilers for:
AMD64 :: cc_amd64.s
Knight :: cc_knight-native.s and cc_knight-posix.s
ARMv7l :: cc_armv7l.s
AA
Today I am proud to announce the release of mescc-tools v0.7.0
https://savannah.nongnu.org/projects/mescc-tools
https://github.com/oriansj/mescc-tools
Featuring AArch64 support, fixes for outstanding ARMv7l bugs and the
elimination of all segfaults found via fuzzing and static code analysis
Not
> We are pleased to announce the release of GNU Mes 0.22, representing
> 57 commits over 8 weeks.
Great job as always Janneke, stage0's 0.3.0 release last week was far less
impressive.
-Jeremiah
___
rb-general@lists.reproducible-builds.org mailing list
> A little bit of a pointer regarding the Mes compiler work.
Always important detail: MesCC is the C compiler written in scheme, Mes.c is
the scheme interpreter
> I discussed this with Janneke and Vagrant on IRC, but I don't think this work
> is really proving DDC as explained by David.
It abso
> I'm not absolutely convinced that reproducible builds does not help with the
> trusting trust attack.
Well one wouldn't want to help the trusting trust attack, one tries to defend
one's self against it
> It all boils down as to where did a backdooring compiler come from, and how
> is it back
> TLDR:
> The goal of reproducible builds is to reduce the likelyhood of running
> software that was corrupted (during build)
Absolutely correct.
For those that worry about the trusting trust attack, we have bootstrappable
builds
#bootstrappable on freenode (irc)
https://bootstrappable.org/
-Je
I am proud to announce the release of mescc-tools-seed v1.1
https://github.com/oriansj/mescc-tools-seed
Capable of bootstrapping from a simple hex assembler all the way to a
cross-platform C compiler (M2-Planet) and a simplified version of Gnu MES
(mes-m2).
Work is still on going to finish a FUL
> I get a giggle now and again when the concept of reproducible builds appears
> in some other cultural context. Such as this week, in a webcomic!
> (Context: steampunk universe; mad geniuses everywhere, generally building
> gadgets and then thinking about the consequences later; and at this mom
> I agree that we don't want to disable IPython address output during
> interactive use. Options:
> - jupyter-nbconvert may well be a suitable "documentation builds go through
> here, interactive use doesn't" place to disable address output by default
> (either by passing a "disable address out
I am pleased to announce version 1.0 of mescc-tools-seed
https://github.com/oriansj/mescc-tools-seed
For those not familiar it is the full bootstrap of a cross-platform C compiler
(written in C) from hex
https://github.com/oriansj/M2-Planet
https://savannah.nongnu.org/projects/mescc-tools
and on
> thanks. whats knight? :)
Knight is an ancient 16/32/64bit Big Endian architecture which can be
implemented in TTL
https://github.com/oriansj/stage0/blob/master/ISA_HEX_Map.org#instruction-listing
The Knight-Native port is to run the compiler on Bare metal and thus eliminate
everything else fr
> neato & thanks for sharing. what are those 5 architectures? looking *very
> briefly* add the above two URLs I couldnt figure it out...
Knight-native
Knight-Posix
ARM (v6+v7)
X86
AMD64
-Jeremiah
___
rb-general@lists.reproducible-builds.org mailing list
Today I am pleased to announce the release of M2-Planet v1.3.0 and 0.6.1
https://github.com/oriansj/M2-Planet
https://savannah.nongnu.org/projects/mescc-tools
Which includes a self-hosting port to its Fifth Architecture.
For those who are not aware M2-Planet is a self-hosting C compiler written i
I am pleased to announce the release which includes ports to ARM and a hand
written hex0 to M0 bootstrap for AMD64
https://github.com/oriansj/M2-Planet
https://savannah.nongnu.org/projects/mescc-tools
-Jeremiah
___
rb-general@lists.reproducible-builds.o
> Of course! There will always be one more layer which we, to paraphrase the
> adage, trust but do not verify.
Well verifying base physics and chemistry tends to get extremely expensive (Who
was got a few billion for a particle accelerator?)
> The goal of the exercise is not to _extinguish_ th
> I'd like to crowdfund an audit of Intel's 8086 CPU¹.
Waste of time and money
> Ultimately, nice though reproducible builds may be, if we are to avoid RoTT
> attacks we must have audited, verified hardware as well.
Actually you need full lithography process control, which is what libresilicon
i
>> Similarly to other interpreted
>>languages, the compiler options used are stashed in the binary for later use.
>I don't know what everyone else here believes, but I recommend that those not
>be included in the binaries at all, but instead be put elsewhere so they can
>be more easily separated.
> I'm not sure what you mean by 'not possible to collide' here. Hashes are
> typically smaller than the allowed inputs, which means there must exist
> different input files that produce the
> same output hash. A cryptographic hash just makes those collisions hard to
> find/create, it cannot pre
> While I agree that you can certainly find collisions when you do
> crc16(H(a),H(b))
> or
> H(crc16(a),crc16(b))
> I fail to see how that would be possible with cryptographic hash functions
> like SHA-256, so
> H(H(a),H(b))
> especially since the hash functions internally usually work in rounds
41 matches
Mail list logo
