Mailing List Archive

SHA-1 has just been broken
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

( you know I hate the Schmoog, and didn't take their cookies, and so
they didn't show me their page in my Palemoon --working great here!, an
Angel of Honesty in comparison to Firefox --and if anybody else don't
want Schmoog prying in his machine, likely:

$ wget \
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

will do just fine as it did for me. )


--
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Re: SHA-1 has just been broken [ In reply to ]
On Saturday, February 25, 2017, Miroslav Rovis <miro.rovis@croatiafidelis.hr>
wrote:
>
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
>
> --
> Miroslav Rovis
> Zagreb, Croatia
> http://www.CroatiaFidelis.hr
>

Very interesting. The first useful SHA-1 collision was, if I remember, done
in 2015, and subverted an HTTPS certificate (though not one which had been
issued). This was some guys with a couple of servers lined with graphics
cards.

Seeing someone manage to do it in a garage a number of years before it was
cosidered feasible should, hopefully, make you have more conservative
estimates of the strength of modern cryptography.

Aside:
http://ecrypt-eu.blogspot.com/2015/11/break-dozen-secret-keys-get-million.html

R0b0t1.
Re: SHA-1 has just been broken [ In reply to ]
On 170225-21:34-0600, R0b0t1 wrote:
> On Saturday, February 25, 2017, Miroslav Rovis <miro.rovis@croatiafidelis.hr>
> wrote:
> >
> https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
...
>
> Very interesting. The first useful SHA-1 collision was, if I remember, done
> in 2015, and subverted an HTTPS certificate (though not one which had been
> issued). This was some guys with a couple of servers lined with graphics
> cards.
>
> Seeing someone manage to do it in a garage a number of years before it was
> cosidered feasible should, hopefully, make you have more conservative
> estimates of the strength of modern cryptography.
>
> Aside:
> http://ecrypt-eu.blogspot.com/2015/11/break-dozen-secret-keys-get-million.html

Too technical for me. Too little learning gain for too much mumbo-jumbo noise, at this
stage of my understanding of crypto, for me.

> R0b0t1.

But, when we talk crypto being broken, I can help thinking of other
threats to Gentoo and other FOSS GNU Linux that I fear are perfectly
feasible (for the resourceful subjects)

Gentoo distro is increasingly served the insecure way, IMO, that is: via
git, without the repositories being, for end users, PGP-verifiable.

And via a new private big business, the Github. Giving over all users to
big Github brother.

And, in the trasition all the history got lost. Git started remembering
only from 2015.

I have asked a question about getting git-served repository verifiable
for end users, but I didn't get any replies:

Date: Tue, 20 Dec 2016 00:47:56 +0100

Message-ID: <20161219234756.GA4008@g0n.xdwgrp>

Subject: Is it safe to switch from webrsync to the git repo now?

if you are subscribed and have three month worth of gentoo-user mail in
your inbox

or:

(same subject as above of course)
https://lists.gt.net/gentoo/dev/320922

Long term, this is an issue that will not go away unless it is fixed,
i.e. git-served portage packages start being PGP-verifiable for end
users.

And when we talk security for privacy, and with... pretty much (at least
from my perspective) privacy experts of today, how about this:

[Secure Desktops] dbus, gnunet (was: unstable dnssec-root)
https://secure-os.org/pipermail/desktops/2017-February/000180.html

(
where note the dbus creating encrypted session, and the link thereto:
How to avoid stealth installation of systemd?
http://forums.debian.net/viewtopic.php?f=20&t=116770&start=45#p552566

)

Regards!
-
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr
Re: SHA-1 has just been broken [ In reply to ]
On Sun, Feb 26, 2017 at 5:00 AM, Miroslav Rovis
<miro.rovis@croatiafidelis.hr> wrote:
> On 170225-21:34-0600, R0b0t1 wrote:
>> On Saturday, February 25, 2017, Miroslav Rovis <miro.rovis@croatiafidelis.hr>
>> wrote:
>> >
>> https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
> ...
>>
>> Very interesting. The first useful SHA-1 collision was, if I remember, done
>> in 2015, and subverted an HTTPS certificate (though not one which had been
>> issued). This was some guys with a couple of servers lined with graphics
>> cards.
>>
>> Seeing someone manage to do it in a garage a number of years before it was
>> cosidered feasible should, hopefully, make you have more conservative
>> estimates of the strength of modern cryptography.
>>
>> Aside:
>> http://ecrypt-eu.blogspot.com/2015/11/break-dozen-secret-keys-get-million.html
>
> Too technical for me. Too little learning gain for too much mumbo-jumbo noise, at this
> stage of my understanding of crypto, for me.
>

My apologies. The useful part of the link is really the title. It
explains how, if you *do* successfully break a given key, you have
necessarily broken millions of them - you are just unsure if they are
currently in use. The wise option is then to record every key
combination you brute force in the hope that someone will start using
it in the future.

>> R0b0t1.
>
> But, when we talk crypto being broken, I can help thinking of other
> threats to Gentoo and other FOSS GNU Linux that I fear are perfectly
> feasible (for the resourceful subjects)
>
> Gentoo distro is increasingly served the insecure way, IMO, that is: via
> git, without the repositories being, for end users, PGP-verifiable.
>
> And via a new private big business, the Github. Giving over all users to
> big Github brother.
>
> And, in the trasition all the history got lost. Git started remembering
> only from 2015.
>
> I have asked a question about getting git-served repository verifiable
> for end users, but I didn't get any replies:
>

This is something I was concerned about myself, especially since the
bare git protocol that most users access the repository from, even if
it is the repository hosted by the Gentoo Foundation, is insecure. Git
access via SSH or HTTPS *is* secure but is not implemented - I'm not
sure why, as they've purchased a "real" certificate and the Git
subdomain may already be covered by it.

> -
> Miroslav Rovis
> Zagreb, Croatia
> https://www.CroatiaFidelis.hr

Well, maybe someone will noticed this message. Or not.

R0b0t1.
Re: SHA-1 has just been broken [ In reply to ]
On 170226-14:32-0600, R0b0t1 wrote:
> On Sun, Feb 26, 2017 at 5:00 AM, Miroslav Rovis
> <miro.rovis@croatiafidelis.hr> wrote:
> > On 170225-21:34-0600, R0b0t1 wrote:
> >> On Saturday, February 25, 2017, Miroslav Rovis <miro.rovis@croatiafidelis.hr>
> >> wrote:
> >> >
> >> https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
> > ...
> >>
...
> >> Aside:
> >> http://ecrypt-eu.blogspot.com/2015/11/break-dozen-secret-keys-get-million.html
> >
> > Too technical for me. Too little learning gain for too much mumbo-jumbo noise, at this
> > stage of my understanding of crypto, for me.
>
> My apologies. The useful part of the link is really the title. It
> explains how, if you *do* successfully break a given key, you have
> necessarily broken millions of them - you are just unsure if they are
> currently in use. The wise option is then to record every key
> combination you brute force in the hope that someone will start using
> it in the future.
I did figure that much out. But all of it useful... for true
cryptographers. It's so appealing, but so distant yet (or forever, where
can one find the time to learn that much?).
> >
> > But, when we talk crypto being broken, I can help thinking of other
I meant:
But, when we talk crypto being broken, I can't help thinking of other
( ... can't ... )
> > threats to Gentoo and other FOSS GNU Linux that I fear are perfectly
> > feasible (for the resourceful subjects)
( And also, the Message-ID given in my email can only be found by
subcribers to the gentoo-dev mailing list, not gentoo-user ML. )
> > Gentoo distro is increasingly served the insecure way, IMO, that is: via
> > git, without the repositories being, for end users, PGP-verifiable.
> >
> > And via a new private big business, the Github. Giving over all users to
> > big Github brother.
> >
> > And, in the trasition all the history got lost. Git started remembering
> > only from 2015.
> >
> > I have asked a question about getting git-served repository verifiable
> > for end users, but I didn't get any replies:
> >
>
> This is something I was concerned about myself, especially since the
> bare git protocol that most users access the repository from, even if
> it is the repository hosted by the Gentoo Foundation, is insecure. Git
> access via SSH or HTTPS *is* secure but is not implemented - I'm not
> sure why, as they've purchased a "real" certificate and the Git
> subdomain may already be covered by it.
>
And there's even no need purchasing certs any more. LetsEncrypt
cetrificates are free in both some GNU/GNU-compatible way, and the
free-of-charge way.

But a repository can also really be verifiable only if it is PGP-signed
(or some other cryptro-verifiable-way signed). So HTTPS alone does not
do it.

> Well, maybe someone will noticed this message. Or not.
>
> R0b0t1.
>

I hope too.

Because it's depressing how large swathes of FOSS are getting under
control of big business and to some extent, very minor here, but not
negligeable, actually covertly privatized...

I can't help but remind ( I wrote about it in:
GUI-less (non-dbus) virt-manager (to run Tails in Gentoo)
https://lists.gt.net/gentoo/user/321797
Message-ID: <20170111205529.GB28353@g0n.xdwgrp>
) how big dirty stingy Schmoogle the Schmoog treats Gentoo which it uses
for its CoreOS
[.[. important thing there to find is the link to:
Gentoo Foundation, background and status report Robin Johnson
https://youtu.be/S3bmXVbxMgE
and if a reader don't get to the same conclusion about the Schmoog that
I arrived at, then the reader might be missing something ]]

Ah, as far as distribution verifiability, I guess emerge-webrsync and
PGP-signed portage trees functionality needs to be kept forever, then...

Thanks for replying!
(
BTW, about the link, in the first email, to my message to secure-os ML,
one of the secure-os folks kindly confirmed, but in a private message,
that they were considering my email...
)

Sad how this topic, or the other linked in my first mail, to the
gentoo-dev ML, didn't attract more discussion... It can't be too late to
fix these issues...

Regards!

--
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr
Re: SHA-1 has just been broken [ In reply to ]
On Sat, 25 Feb 2017 22:12:10 +0100 Miroslav Rovis wrote:
> https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
>
> ( you know I hate the Schmoog, and didn't take their cookies, and so
> they didn't show me their page in my Palemoon --working great here!, an
> Angel of Honesty in comparison to Firefox --and if anybody else don't
> want Schmoog prying in his machine, likely:

Mass generation of collisions is much easier if document structure
is taken into account, e.g. for PDF it is sufficient to compute
collision block once and it is possible to generate different PDFs
with the same SHA1 hash.

On-line service is available together with detailed description:
https://alf.nu/SHA1

So danger of SHA1 collision is much closer than
9,223,372,036,854,775,808 SHA1 computations or 1 110-GPU year.

Best regards,
Andrew Savchenko
Re: SHA-1 has just been broken [ In reply to ]
On Mon, Feb 27, 2017 at 9:46 AM, Andrew Savchenko <bircoph@gentoo.org> wrote:
>
> So danger of SHA1 collision is much closer than
> 9,223,372,036,854,775,808 SHA1 computations or 1 110-GPU year.

Indeed in every way it is closer than that than when Google started
their project, and tomorrow it will be closer still.

The subject line shouldn't really be "SHA-1 has just been broken" but
"Another recent confirmation of SHA-1 being broken." We've known it
has been broken for quite a while.

In the same way, DES wasn't broken when the EFF built their ASIC-based
machine. That was just the final nail in the coffin. Anybody who
waited for somebody to actually build that machine (and I'd be shocked
if bigger players than the EFF didn't have such a machine much sooner)
was deluded.

When somebody discovers an attack on a hash function that greatly
reduces the cost to generate collisions into a number that is even
remotely forseeable in the next decade, it is time to stop using that
hash function. Sheer inertia ensures that even if everybody started
changing overnight it probably would still cause problems when the
attacks start getting practical.

Sure, there are threat models where it doesn't matter, but on the
SHA-1 front it seems like people have been underestimating their
exposure. Certainly Gentoo has exposure until git is fixed and the
active tree has non-SHA-1 hashes. Even then the historical tree is
vulnerable if we don't rehash everything, though in practice I don't
think that matters as much, and obviously slipping a non-preimage
collision into the historical tree is impossible unless it is done
before the hash functions are changed.

Sure, you can wave your hands about how hard it is to expoit in
practice, and I agree with many of these arguments. However, SHA-1
should be viewed as a vulnerability and fixing it as a priority. For
Gentoo specifically it isn't really the weakest link in the chain as
was pointed out in the other thread, so I'm not sure I'd go rushing
out to fork git. Still, we shouldn't be entirely comfortable with git
as it stands at the moment.

--
Rich
Re: SHA-1 has just been broken [ In reply to ]
On Sun, 26 Feb 2017 12:00:50 +0100 Miroslav Rovis wrote:

> But, when we talk crypto being broken,

Git is not in the immediate threat due to SHA1 collision being
practical. See Linux blog about this:

https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL

Note that git devs are working on moving to a more secure hash
function.

Also note that git can handle several files in the repo with the
same hash function. While this doesn't protect from the possible
repo forgery, it protects from accidental file collision where
subversion fails badly:
https://www.bleepingcomputer.com/news/security/sha1-collision-attack-makes-its-first-victim-subversion-repositories/

I do not want to offence subversion devs, but they haven't even
considered the possibility that hash function may collide. Huge
blunder on their side.

> I can help thinking of other
> threats to Gentoo and other FOSS GNU Linux that I fear are perfectly
> feasible (for the resourceful subjects)
>
> Gentoo distro is increasingly served the insecure way, IMO, that is: via
> git, without the repositories being, for end users, PGP-verifiable.

It is verifiable for end users, but not in an easy way. You can
either use web rsync or verify git commits yourself using gpupg and
gkeys.

> And via a new private big business, the Github. Giving over all users to
> big Github brother.

???
Github is entirely optional and is only for those who want to use it
(we have both users and devs willing so), but in no way anyone
demands its usage.

If you want to have sync-friendly git repo, Gentoo infra provides
one for you:
https://gitweb.gentoo.org/repo/sync/gentoo.git/

> And, in the trasition all the history got lost. Git started remembering
> only from 2015.

No, it isn't. Full historical git repo is available:
https://gitweb.gentoo.org/repo/gentoo/historical.git/

One may use git graft to join historical and actual repo together.

> I have asked a question about getting git-served repository verifiable
> for end users, but I didn't get any replies:

Do not forget that all devs are volunteers. User-transparent
GnuPG tree verification is indeed important. You can help! Join
gkeys project, get in touch with infra, discuss what needs to be
done. Don't just rattle about how insecure data is provided, help
to make it secure! (And as I shown above actual state is not
that bad and some options are already available.)

Best regards,
Andrew Savchenko
Re: SHA-1 has just been broken [ In reply to ]
On 26/02/2017 22:32, R0b0t1 wrote:
> On Sun, Feb 26, 2017 at 5:00 AM, Miroslav Rovis
> <miro.rovis@croatiafidelis.hr> wrote:
>> On 170225-21:34-0600, R0b0t1 wrote:
>>> On Saturday, February 25, 2017, Miroslav Rovis <miro.rovis@croatiafidelis.hr>
>>> wrote:
>>>>
>>> https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
>> ...
>>>
>>> Very interesting. The first useful SHA-1 collision was, if I remember, done
>>> in 2015, and subverted an HTTPS certificate (though not one which had been
>>> issued). This was some guys with a couple of servers lined with graphics
>>> cards.
>>>
>>> Seeing someone manage to do it in a garage a number of years before it was
>>> cosidered feasible should, hopefully, make you have more conservative
>>> estimates of the strength of modern cryptography.
>>>
>>> Aside:
>>> http://ecrypt-eu.blogspot.com/2015/11/break-dozen-secret-keys-get-million.html
>>
>> Too technical for me. Too little learning gain for too much mumbo-jumbo noise, at this
>> stage of my understanding of crypto, for me.
>>
>
> My apologies. The useful part of the link is really the title. It
> explains how, if you *do* successfully break a given key, you have
> necessarily broken millions of them - you are just unsure if they are
> currently in use. The wise option is then to record every key
> combination you brute force in the hope that someone will start using
> it in the future.
>
>>> R0b0t1.
>>
>> But, when we talk crypto being broken, I can help thinking of other
>> threats to Gentoo and other FOSS GNU Linux that I fear are perfectly
>> feasible (for the resourceful subjects)
>>
>> Gentoo distro is increasingly served the insecure way, IMO, that is: via
>> git, without the repositories being, for end users, PGP-verifiable.
>>
>> And via a new private big business, the Github. Giving over all users to
>> big Github brother.
>>
>> And, in the trasition all the history got lost. Git started remembering
>> only from 2015.
>>
>> I have asked a question about getting git-served repository verifiable
>> for end users, but I didn't get any replies:
>>
>
> This is something I was concerned about myself, especially since the
> bare git protocol that most users access the repository from, even if
> it is the repository hosted by the Gentoo Foundation, is insecure. Git
> access via SSH or HTTPS *is* secure but is not implemented - I'm not
> sure why, as they've purchased a "real" certificate and the Git
> subdomain may already be covered by it.

I always though git's use of SHA hashes was to identify commits and
detect random bit flips, not to provide any measure of security.


--
Alan McKinnon
alan.mckinnon@gmail.com
Re: SHA-1 has just been broken [ In reply to ]
On Mon, Feb 27, 2017 at 1:02 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
> I always though git's use of SHA hashes was to identify commits and
> detect random bit flips, not to provide any measure of security.
>

As somebody said in Twitter recently (and Linus to some degree in his
post), it is, except when it isn't.

git supports gpg signatures on tags and commits. The only thing that
binds these signatures to the information being signed are sha1 hashes
and file sizes, and Google has already demonstrated the ability to
manipulate hashes without changing file size.

Those hashes apply to blobs and trees, and doing a collision on either
lets you modify the contents of the tree.

Now, if every commit is being carefully reviewed (via git diff/etc)
then the chances of leaking the data needed to make collisions less
expensive into the repo is low, as long as you're talking exclusively
about text files (which is all we store in the tree). If you go
storing pdfs or images/etc in a repo I'm less confident that you could
detect attempts to sneak easy-to-collide data into a repo.

So, this isn't a reason to panic, but it is a reason for concern.
People have been talking about sha-1 collisions for a while.

Commit signatures are not the only way to secure the Gentoo
repository, but they seem like one of the most convenient to use,
assuming we could trust them. I've always seen sha1 brought up as one
of the biggest reasons not to.

--
Rich
Re: SHA-1 has just been broken [ In reply to ]
Apologies for my not being able to reply sooner!

On 170227-18:18+0300, Andrew Savchenko wrote:
> On Sun, 26 Feb 2017 12:00:50 +0100 Miroslav Rovis wrote:
>
> > But, when we talk crypto being broken,
>
> Git is not in the immediate threat due to SHA1 collision being
> practical. See Linux blog about this:
>
> https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL
Will read it. (it's 02:00 past midnight CET)

> Note that git devs are working on moving to a more secure hash
> function.
Good to hear!

> Also note that git can handle several files in the repo with the
> same hash function. While this doesn't protect from the possible
> repo forgery, it protects from accidental file collision where
> subversion fails badly:
> https://www.bleepingcomputer.com/news/security/sha1-collision-attack-makes-its-first-victim-subversion-repositories/
Pretty sad!
> I do not want to offence subversion devs, but they haven't even
> considered the possibility that hash function may collide. Huge
> blunder on their side.
>
> > I can help thinking of other
> > threats to Gentoo and other FOSS GNU Linux that I fear are perfectly
> > feasible (for the resourceful subjects)
> >
> > Gentoo distro is increasingly served the insecure way, IMO, that is: via
> > git, without the repositories being, for end users, PGP-verifiable.
>
> It is verifiable for end users, but not in an easy way. You can
> either use web rsync or verify git commits yourself using gpupg and
> gkeys.
I'll try and do that. I have been trying to figure it out, a few times
already, but I would always get lost in the volume of new stuff to
digest... Will need more time to do it.

However I am already using signed portage snapshots via emerge-webrsync,
and I use local mirror. I am pretty safe, but on obsolete technology.

> > And via a new private big business, the Github. Giving over all users to
> > big Github brother.
>
> ???
> Github is entirely optional and is only for those who want to use it
> (we have both users and devs willing so), but in no way anyone
> demands its usage.
Yeah! Still, it would be great if git was used in distributed way, and
not from a central private business...

> If you want to have sync-friendly git repo, Gentoo infra provides
> one for you:
> https://gitweb.gentoo.org/repo/sync/gentoo.git/
Harder to use than Github. Github is foolproof, extremely easy for
newbies, compared to any other git server. The reason for their
success...

> > And, in the trasition all the history got lost. Git started remembering
> > only from 2015.
>
> No, it isn't. Full historical git repo is available:
> https://gitweb.gentoo.org/repo/gentoo/historical.git/
Great to know! Sorry for wrong claims that I made.

> One may use git graft to join historical and actual repo together.
Which is advanced usage for me at this stage.

> > I have asked a question about getting git-served repository verifiable
> > for end users, but I didn't get any replies:
>
> Do not forget that all devs are volunteers.
I know that. Always keep that in mind.

> User-transparent
> GnuPG tree verification is indeed important. You can help!
If I get that savvy in git/portage/other I will... That time is still
distant yet, I'm afraid.

> Join gkeys project, get in touch with infra, discuss what needs to be
> done.
I'll look gkeys up...
> Don't just rattle about how insecure data is provided,
You're right.
> help to make it secure! (And as I shown above actual state is not that
> bad and some options are already available.)
I'm busy figuring how to deploy virtualization on my sans-dbus system,
and have spent months on things like that... and only lately finally
getting there.

Also, practical verifiability in Gentoo is something I have been keen on
for pretty long now.

But you having showed to me (I haven't digested it yet, too late in the
night right now) that verifiability is possibly does make it the next
big wish of mine to apply for my Gentoo
(
and my dream is to help test it, so everybody can use git for verifiable
installations!
).

>
> Best regards,
> Andrew Savchenko

Your email means a lot to me! Thank you!

Good night! (I see other emails, but have to go to sleep now first)
--
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr
Re: SHA-1 has just been broken [ In reply to ]
On Mon, Feb 27, 2017 at 8:10 PM, Miroslav Rovis
<miro.rovis@croatiafidelis.hr> wrote:
> Apologies for my not being able to reply sooner!
>
> On 170227-18:18+0300, Andrew Savchenko wrote:
>
>> > And via a new private big business, the Github. Giving over all users to
>> > big Github brother.
>>
>> ???
>> Github is entirely optional and is only for those who want to use it
>> (we have both users and devs willing so), but in no way anyone
>> demands its usage.
> Yeah! Still, it would be great if git was used in distributed way, and
> not from a central private business...
>

Git can pretty-much ONLY be used in a distributed way. In the sync
workflow github is basically just a mirror. A lot of our mirrors are
run by private businesses, and nobody knows what OS they're even
hosted on, let alone whether the firmware and CPU microcode are FOSS
along with their hard drive firmware.

As far as distribution goes I think github is the wrong thing to worry
about. What you want is traceable signatures from dev to user. Once
you have that you can download from an NSA mirror and there shouldn't
be any risk. All a mirror does is replicate data, and if
modifications are detectable the worst they can do is a DoS.

Most of the concerns that people tend to have with github is that you
can become dependent on them for issue and pull request tracking and
then if they decide to pull the plug you lose all that data. We try
to minimize the use of these features and not make it a core part of
the dev workflow. But, we do use pull requests and in theory we could
lose those someday. The actual code itself gets pushed to the Gentoo
infra Repo from a developer's box using plain old git after they've
inspected/tested/etc it. So, there isn't really any way for Github to
go injecting commits into the repositories we actually use. I guess
they could do it for anybody using our github mirrors on the
distribution side, but that's only because we don't have that all
locked down and the same issue applies with any other mirror (rsync,
etc). Again, you really need end-to-end signature checking to make
any of these things truly safe.

--
Rich
Re: SHA-1 has just been broken [ In reply to ]
On 170227-21:59-0500, Rich Freeman wrote:
> On Mon, Feb 27, 2017 at 8:10 PM, Miroslav Rovis
> <miro.rovis@croatiafidelis.hr> wrote:
> > Apologies for my not being able to reply sooner!
> >
> > On 170227-18:18+0300, Andrew Savchenko wrote:
> >
> >> > And via a new private big business, the Github. Giving over all users to
> >> > big Github brother.
> >>
> >> ???
> >> Github is entirely optional and is only for those who want to use it
> >> (we have both users and devs willing so), but in no way anyone
> >> demands its usage.
> > Yeah! Still, it would be great if git was used in distributed way, and
> > not from a central private business...
> >
>
> Git can pretty-much ONLY be used in a distributed way.
Correct, in that sense. But I didn't express clearly what I meant.

I really meant in this sense (invented quotations in this paragraph):
> Git was intended for everyone to run their own little git server and
> pull from each other. Git was NOT invented for centralized commercial
> social networking clouds such as github!

That was from:
https://wiki.gentoo.org/wiki/Overlay:Youbroketheinternet

> In the sync
> workflow github is basically just a mirror. A lot of our mirrors are
> run by private businesses, and nobody knows what OS they're even
> hosted on, let alone whether the firmware and CPU microcode are FOSS
> along with their hard drive firmware.
I understand that. And I support any honess business. What I hate is
examples like Google, Oracle, Microsoft, IBM is a little more honest, I
think... The few at the control of those ruined so much in computing and
the internet.

GNU and FOSS, to lesser extent OSi, are good, even beautiful, socially
and philosophically.

> As far as distribution goes I think github is the wrong thing to worry
> about. What you want is traceable signatures from dev to user. Once
> you have that you can download from an NSA mirror and there shouldn't
> be any risk. All a mirror does is replicate data, and if
> modifications are detectable the worst they can do is a DoS.
I see.
> Most of the concerns that people tend to have with github is that you
> can become dependent on them for issue and pull request tracking and
> then if they decide to pull the plug you lose all that data. We try
> to minimize the use of these features and not make it a core part of
> the dev workflow.
Good practice!

> But, we do use pull requests and in theory we could
> lose those someday. The actual code itself gets pushed to the Gentoo
> infra Repo from a developer's box using plain old git after they've
> inspected/tested/etc it. So, there isn't really any way for Github to
> go injecting commits into the repositories we actually use. I guess
> they could do it for anybody using our github mirrors on the
> distribution side, but that's only because we don't have that all
> locked down and the same issue applies with any other mirror (rsync,
> etc). Again, you really need end-to-end signature checking to make
> any of these things truly safe.
Absolutely! I did figure that out since long!
> --
> Rich
>

And what I've spent some time doing today, is figuring out about the
info that I finally got from you people!

About time! My rattling was all about whether there was or wasn't a way
to do what is still in the title of that mail that I linked to, and gave
Message-ID of, to do this:

Is it safe to switch from webrsync to the git repo now?

And finally Andrew Shavchenko pointed me to gkeys !

Here's the answer to my query (ah, just the beginning of, my
implementation of it will take time):

emerge -tuDN app-crypt/gkeys app-crypt/gkeys-gen

# equery f gkeys-gen
...
/usr/share/doc/gkeys-gen-0.2/README.md.bz2
...

(
NOTE: The:
/usr/share/doc/gkeys-0.2/README.md.bz2
of the gkeys package is identical.
)

# bzcat /usr/share/doc/gkeys-gen-0.2/README.md.bz2

Gentoo Keys
-----------

### About

Gentoo Keys is a Python based project that aims to manage the GPG keys used
for validation on users and Gentoo's infrastracutre servers. Gentoo Keys will be able
to verify GPG keys used for Gentoo's release media, such as installation CD's,
Live DVD's, packages and other GPG signed documents. It will also be used by
Gentoo infrastructure to achieve GPG signed git commits in the forthcoming git
migration of the main CVS tree.

### License

Gentoo Keys is under GPL-2 License
#

But do I read this correctly?:

...Gentoo Keys will be able
to verify GPG keys used for Gentoo's release media, such as installation CD's,
Live DVD's, packages and other GPG signed documents.

Again, about this (syntactical) object (in the sentence), with other
objects removed:

...Gentoo Keys will be able
to verify GPG keys used for ...
... packages...

Does that mean what I read? That with gkeys any user will be able to get
packages via git, and somehow automatically gpg -verify the signature of
each package that (s)he got when (s)he, say:

emerge -tuDN world

?

Does that mean that?

And then, to achieve true verifiability in the open (machine connected
to online, and doing emerge'ing), you know what is still left to be
done? This:

Write TLS session keys to $SSLKEYLOGFILE #11614
https://github.com/rg3/youtube-dl/issues/11614#issuecomment-271064602

( of course, apply that to git, just the way it has been, and that's so
beautiful to me, applied to wget, kudos to wget maintainer Giuseppe
Scrivano! IIRC his name )

There's no encryption on me, behind my back, in my machine that I can
allow and believe it's fine. No way. It must be allowed by me, asked of
me, and decryptable for me!

( I decided to go without dbus in my life after this happened, behind my
back, with my Debian installation:

How to avoid stealth installation of systemd?
http://forums.debian.net/viewtopic.php?f=20&t=116770&start=45#p552566

PASTING, so readers get a feel about it:

$ ps aux | grep ssh
root 2184 0.0 0.0 54976 1004 ? Ss Sep06 0:00 /usr/sbin/sshd
mr 2447 0.0 0.0 10592 32 ? Ss Sep06 0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager
mr 15141 0.0 0.0 19980 1796 pts/9 S+ 21:48 0:00 grep ssh

PASTED.
)

But, I already spent on this more than I can if I am not to lose track
on other things that I'm now doing (related to virtualization). Will
have to leave this issue very soon now, else I'll have to go over from
scratch in that other work...

Thanks, Rich!

So, do I read those gkeys/gkeys-gen READMEs correctly?

Regards!

--
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr
Re: SHA-1 has just been broken [ In reply to ]
On 02/28/2017 12:05 PM, Miroslav Rovis wrote:

> On 170227-21:59-0500, Rich Freeman wrote:
>> On Mon, Feb 27, 2017 at 8:10 PM, Miroslav Rovis
>> <miro.rovis@croatiafidelis.hr> wrote:
>>> Apologies for my not being able to reply sooner!
>>>
>>> On 170227-18:18+0300, Andrew Savchenko wrote:
>>>
>>>>> And via a new private big business, the Github. Giving over all users to
>>>>> big Github brother.
>>>> ???
>>>> Github is entirely optional and is only for those who want to use it
>>>> (we have both users and devs willing so), but in no way anyone
>>>> demands its usage.
>>> Yeah! Still, it would be great if git was used in distributed way, and
>>> not from a central private business...
>>>
>> Git can pretty-much ONLY be used in a distributed way.
> Correct, in that sense. But I didn't express clearly what I meant.
>
> I really meant in this sense (invented quotations in this paragraph):
>> Git was intended for everyone to run their own little git server and
>> pull from each other. Git was NOT invented for centralized commercial
>> social networking clouds such as github!
> That was from:
> https://wiki.gentoo.org/wiki/Overlay:Youbroketheinternet
>
>> In the sync
>> workflow github is basically just a mirror. A lot of our mirrors are
>> run by private businesses, and nobody knows what OS they're even
>> hosted on, let alone whether the firmware and CPU microcode are FOSS
>> along with their hard drive firmware.
> I understand that. And I support any honess business. What I hate is
> examples like Google, Oracle, Microsoft, IBM is a little more honest, I
> think... The few at the control of those ruined so much in computing and
> the internet.
>
> GNU and FOSS, to lesser extent OSi, are good, even beautiful, socially
> and philosophically.
>
>> As far as distribution goes I think github is the wrong thing to worry
>> about. What you want is traceable signatures from dev to user. Once
>> you have that you can download from an NSA mirror and there shouldn't
>> be any risk. All a mirror does is replicate data, and if
>> modifications are detectable the worst they can do is a DoS.
> I see.
>> Most of the concerns that people tend to have with github is that you
>> can become dependent on them for issue and pull request tracking and
>> then if they decide to pull the plug you lose all that data. We try
>> to minimize the use of these features and not make it a core part of
>> the dev workflow.
> Good practice!
>
>> But, we do use pull requests and in theory we could
>> lose those someday. The actual code itself gets pushed to the Gentoo
>> infra Repo from a developer's box using plain old git after they've
>> inspected/tested/etc it. So, there isn't really any way for Github to
>> go injecting commits into the repositories we actually use. I guess
>> they could do it for anybody using our github mirrors on the
>> distribution side, but that's only because we don't have that all
>> locked down and the same issue applies with any other mirror (rsync,
>> etc). Again, you really need end-to-end signature checking to make
>> any of these things truly safe.
> Absolutely! I did figure that out since long!
>> --
>> Rich
>>
> And what I've spent some time doing today, is figuring out about the
> info that I finally got from you people!
>
> About time! My rattling was all about whether there was or wasn't a way
> to do what is still in the title of that mail that I linked to, and gave
> Message-ID of, to do this:
>
> Is it safe to switch from webrsync to the git repo now?
>
> And finally Andrew Shavchenko pointed me to gkeys !
>
> Here's the answer to my query (ah, just the beginning of, my
> implementation of it will take time):
>
> emerge -tuDN app-crypt/gkeys app-crypt/gkeys-gen
>
> # equery f gkeys-gen
> ...
> /usr/share/doc/gkeys-gen-0.2/README.md.bz2
> ...
>
> (
> NOTE: The:
> /usr/share/doc/gkeys-0.2/README.md.bz2
> of the gkeys package is identical.
> )
>
> # bzcat /usr/share/doc/gkeys-gen-0.2/README.md.bz2
>
> Gentoo Keys
> -----------
>
> ### About
>
> Gentoo Keys is a Python based project that aims to manage the GPG keys used
> for validation on users and Gentoo's infrastracutre servers. Gentoo Keys will be able
> to verify GPG keys used for Gentoo's release media, such as installation CD's,
> Live DVD's, packages and other GPG signed documents. It will also be used by
> Gentoo infrastructure to achieve GPG signed git commits in the forthcoming git
> migration of the main CVS tree.
>
> ### License
>
> Gentoo Keys is under GPL-2 License
> #
>
> But do I read this correctly?:
>
> ...Gentoo Keys will be able
> to verify GPG keys used for Gentoo's release media, such as installation CD's,
> Live DVD's, packages and other GPG signed documents.
>
> Again, about this (syntactical) object (in the sentence), with other
> objects removed:
>
> ...Gentoo Keys will be able
> to verify GPG keys used for ...
> ... packages...
>
> Does that mean what I read? That with gkeys any user will be able to get
> packages via git, and somehow automatically gpg -verify the signature of
> each package that (s)he got when (s)he, say:
>
> emerge -tuDN world
>
> ?
>
> Does that mean that?
>
> And then, to achieve true verifiability in the open (machine connected
> to online, and doing emerge'ing), you know what is still left to be
> done? This:
>
> Write TLS session keys to $SSLKEYLOGFILE #11614
> https://github.com/rg3/youtube-dl/issues/11614#issuecomment-271064602
>
> ( of course, apply that to git, just the way it has been, and that's so
> beautiful to me, applied to wget, kudos to wget maintainer Giuseppe
> Scrivano! IIRC his name )
>
> There's no encryption on me, behind my back, in my machine that I can
> allow and believe it's fine. No way. It must be allowed by me, asked of
> me, and decryptable for me!
>
> ( I decided to go without dbus in my life after this happened, behind my
> back, with my Debian installation:
>
> How to avoid stealth installation of systemd?
> http://forums.debian.net/viewtopic.php?f=20&t=116770&start=45#p552566
>
> PASTING, so readers get a feel about it:
>
> $ ps aux | grep ssh
> root 2184 0.0 0.0 54976 1004 ? Ss Sep06 0:00 /usr/sbin/sshd
> mr 2447 0.0 0.0 10592 32 ? Ss Sep06 0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager
> mr 15141 0.0 0.0 19980 1796 pts/9 S+ 21:48 0:00 grep ssh
>
> PASTED.
> )
>
> But, I already spent on this more than I can if I am not to lose track
> on other things that I'm now doing (related to virtualization). Will
> have to leave this issue very soon now, else I'll have to go over from
> scratch in that other work...
>
> Thanks, Rich!
>
> So, do I read those gkeys/gkeys-gen READMEs correctly?
>
> Regards!
>
It is possible to have a reasonably secure system where the hard drive
firmware (or any other devices) can't fuck around with the stuff on
disk, although I highly doubt that the gentoo infrastructure (and
kernel.org, and all the source repos for all the other software) does this

One way is to use a blob-free coreboot IOMMU supporting board and
bootstrap the crypto/kernel off of the board firmware EEPROM chip to
load the initial kernel thus no plaintext touches the disk and thus
nothing can mess with it.

The IOMMU (theoretically) protects the CPU and memory from rogue
devices, such as the hard drive.

In terms of ethics IBM *for now* is a way better company than Intel/AMD,
their POWER servers are owner controlled as there isn't any boot
guard/secure boot/management engine/platform "security" processor (amd's
ME) to stop you from re-writing the firmware as you please. They also
have an getting-there-almost-reasonable open source effort (OpenPOWER)

You can buy a TYAN OpenPOWER8 "Palmetto" (100% FOSS out of the box,
although not that powerful) or an IBM POWER8 S822 "Firestone" (very
powerful) which needs only a small amount of final work to be open sourced.

IBM's POWER8 has a supervisor processor, although it is owner controlled
(the key difference) unlike ME/PSP.

It is a shame that TALOS (POWER workstation board) never went anywhere,
it seems the linux community won't care about real freedom - right up
until microsoft finally locks us out for good and it is too late to do
anything about it.

https://www.coreboot.org/Board_freedom_levels
Re: SHA-1 has just been broken [ In reply to ]
On 170302-03:42-0500, Taiidan@gmx.com wrote:
> On 02/28/2017 12:05 PM, Miroslav Rovis wrote:
>
> > On 170227-21:59-0500, Rich Freeman wrote:
> >> On Mon, Feb 27, 2017 at 8:10 PM, Miroslav Rovis
> >> <miro.rovis@croatiafidelis.hr> wrote:
...
> > And finally Andrew Shavchenko pointed me to gkeys !
> >
> > Here's the answer to my query (ah, just the beginning of, my
> > implementation of it will take time):
> >
> > emerge -tuDN app-crypt/gkeys app-crypt/gkeys-gen
> >
> > # equery f gkeys-gen
> > ...
> > /usr/share/doc/gkeys-gen-0.2/README.md.bz2
> > ...
> >
> > (
> > NOTE: The:
> > /usr/share/doc/gkeys-0.2/README.md.bz2
> > of the gkeys package is identical.
> > )
> >
> > # bzcat /usr/share/doc/gkeys-gen-0.2/README.md.bz2
> >
> > Gentoo Keys
> > -----------
> >
> > ### About
> >
> > Gentoo Keys is a Python based project that aims to manage the GPG keys used
> > for validation on users and Gentoo's infrastracutre servers. Gentoo Keys will be able
> > to verify GPG keys used for Gentoo's release media, such as installation CD's,
> > Live DVD's, packages and other GPG signed documents. It will also be used by
> > Gentoo infrastructure to achieve GPG signed git commits in the forthcoming git
> > migration of the main CVS tree.
> >
> > ### License
> >
> > Gentoo Keys is under GPL-2 License
> > #
> >
> > But do I read this correctly?:
> >
> > ...Gentoo Keys will be able
> > to verify GPG keys used for Gentoo's release media, such as installation CD's,
> > Live DVD's, packages and other GPG signed documents.
> >
> > Again, about this (syntactical) object (in the sentence), with other
> > objects removed:
> >
> > ...Gentoo Keys will be able
> > to verify GPG keys used for ...
> > ... packages...
> >
> > Does that mean what I read? That with gkeys any user will be able to get
> > packages via git, and somehow automatically gpg -verify the signature of
> > each package that (s)he got when (s)he, say:
> >
> > emerge -tuDN world
> >
> > ?
> >
> > Does that mean that?
> >
...
> It is possible to have a reasonably secure system where the hard drive
> firmware (or any other devices) can't fuck around with the stuff on
> disk, although I highly doubt that the gentoo infrastructure (and
> kernel.org, and all the source repos for all the other software) does this
Rogue elements everywhere (even the most known Person in the world,
throughout the history (which counts from His birth), had His traitors),
but you are correct, it is still little likely.

I'll keep you thought below for reference, when I some day, find more
time to learn about these things:
> One way is to use a blob-free coreboot IOMMU supporting board and
> bootstrap the crypto/kernel off of the board firmware EEPROM chip to
> load the initial kernel thus no plaintext touches the disk and thus
> nothing can mess with it.
>
> The IOMMU (theoretically) protects the CPU and memory from rogue
> devices, such as the hard drive.
>
> In terms of ethics IBM *for now* is a way better company than Intel/AMD,
> their POWER servers are owner controlled as there isn't any boot
> guard/secure boot/management engine/platform "security" processor (amd's
> ME) to stop you from re-writing the firmware as you please. They also
> have an getting-there-almost-reasonable open source effort (OpenPOWER)
>
> You can buy a TYAN OpenPOWER8 "Palmetto" (100% FOSS out of the box,
> although not that powerful) or an IBM POWER8 S822 "Firestone" (very
> powerful) which needs only a small amount of final work to be open sourced.
>
> IBM's POWER8 has a supervisor processor, although it is owner controlled
> (the key difference) unlike ME/PSP.
>
> It is a shame that TALOS (POWER workstation board) never went anywhere,
> it seems the linux community won't care about real freedom - right up
> until microsoft finally locks us out for good and it is too late to do
> anything about it.
>
> https://www.coreboot.org/Board_freedom_levels

Yes, I looked up that page, and searched a little about Power8
pocessors... I wish I was aware how important Board freedom is back four
and a half years ago. Not so ugly what I have, but neither is open hardware
(
Asrock
Extreme4, a few of them (so I can clone the systems):
Use old amd64 gentoo image on new amd64 hardware, possible?
https://forums.gentoo.org/viewtopic-t-940916.html#7172822

I can't believe they're still selling them! If I'm not mistaken:
http://www.asrock.com/mb/AMD/970%20Extreme4/
I have to say, they are really not bad, but are not openhardware either.
)

I can't follow all the info that you gave, it's too advanced for me (at
least at this time).

And I couldn't reply sooner... I had to finish, finally successfully,
some steep learning of mine about how to use virtualization.

Voilà:

Devuan's precursor's, as Tails, image in Qemu (10)
https://www.croatiafidelis.hr/foss/cap/cap-161015-qemu-devuan/qemu-devuan-10.php

Finally using Tails from my grsecurity-hardened Gentoo, in a
VirtualMachine! Finally I can do it! Took me months!

(
[[ might be of interest to grsecurity-hardeners ]]
Ah, what you can't find there (simply because I forgot to give the link
to is), is this:

Libvirt virtualization policies
https://forums.grsecurity.net/viewtopic.php?f=5&t=4675
)

The most important/urgent among really great messages that I got in this
thread, is Shavchenko's message about the gkeys !

And I'm still wondering:

Does anybody have a way to, as I wrote, be pulling packages via git, when
doing building/installing with emerge, and be verifying each package as
(s)he is pulling them automatically, with gkeys ?

That _must_ be waiting for us in the future of Gentoo ;-)

gkeys <------ !!! That looks like the solution that I have dreamed about!

Regards!

--
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr
Re: SHA-1 has just been broken [ In reply to ]
On Thu, 2 Mar 2017 03:42:24 -0500 Taiidan@gmx.com wrote:
> It is possible to have a reasonably secure system where the hard drive
> firmware (or any other devices) can't fuck around with the stuff on
> disk, although I highly doubt that the gentoo infrastructure (and
> kernel.org, and all the source repos for all the other software) does this

Hard drive's firmware is a drive's micro OS, it can manipulate data
on the disk as it pleases. The only way to protect privacy of the
data is to write it already encrypted, so it still can be mangled
and become unusable, but privacy will be kept. But see below about
DMA.

> One way is to use a blob-free coreboot IOMMU supporting board and
> bootstrap the crypto/kernel off of the board firmware EEPROM chip to
> load the initial kernel thus no plaintext touches the disk and thus
> nothing can mess with it.
>
> The IOMMU (theoretically) protects the CPU and memory from rogue
> devices, such as the hard drive.

No. Any DMA capable device can bypass IOMMU. IOMMU was not
designed to protect OS from device.

> In terms of ethics IBM *for now* is a way better company than Intel/AMD,
> their POWER servers are owner controlled as there isn't any boot
> guard/secure boot/management engine/platform "security" processor (amd's
> ME) to stop you from re-writing the firmware as you please. They also
> have an getting-there-almost-reasonable open source effort (OpenPOWER)

Indeed they are. But that boxes are quite expensive and hard to get.

Best regards,
Andrew Savchenko
Re: SHA-1 has just been broken [ In reply to ]
On Tue, 28 Feb 2017 18:05:29 +0100 Miroslav Rovis wrote:
[...]
> Gentoo Keys
> -----------
>
> ### About
>
> Gentoo Keys is a Python based project that aims to manage the GPG keys used
> for validation on users and Gentoo's infrastracutre servers. Gentoo Keys will be able
> to verify GPG keys used for Gentoo's release media, such as installation CD's,
> Live DVD's, packages and other GPG signed documents. It will also be used by
> Gentoo infrastructure to achieve GPG signed git commits in the forthcoming git
> migration of the main CVS tree.
>
> ### License
>
> Gentoo Keys is under GPL-2 License
> #
>
> But do I read this correctly?:
>
> ...Gentoo Keys will be able
> to verify GPG keys used for Gentoo's release media, such as installation CD's,
> Live DVD's, packages and other GPG signed documents.
>
> Again, about this (syntactical) object (in the sentence), with other
> objects removed:
>
> ...Gentoo Keys will be able
> to verify GPG keys used for ...
> ... packages...
>
> Does that mean what I read? That with gkeys any user will be able to get
> packages via git, and somehow automatically gpg -verify the signature of
> each package that (s)he got when (s)he, say:

Yes and no. AFAIK gkeys is not yet fully implemented. Right now it
can be used to verify dev keys, but I'm not aware about a way to
verity git tree using gkeys. Probably this should be done at the
end of emaint sync process.

Best regards,
Andrew Savchenko
Re: SHA-1 has just been broken [ In reply to ]
On Thu, Mar 2, 2017 at 6:26 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
> On Thu, 2 Mar 2017 03:42:24 -0500 Taiidan@gmx.com wrote:
>>
>> The IOMMU (theoretically) protects the CPU and memory from rogue
>> devices, such as the hard drive.
>
> No. Any DMA capable device can bypass IOMMU. IOMMU was not
> designed to protect OS from device.
>

Huh? I thought protection against DMA attacks was half the reason for
an IOMMU in the first place.

https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit

--
Rich
Re: SHA-1 has just been broken [ In reply to ]
On 03/02/2017 06:26 PM, Andrew Savchenko wrote:

> On Thu, 2 Mar 2017 03:42:24 -0500 Taiidan@gmx.com wrote:
>> It is possible to have a reasonably secure system where the hard drive
>> firmware (or any other devices) can't fuck around with the stuff on
>> disk, although I highly doubt that the gentoo infrastructure (and
>> kernel.org, and all the source repos for all the other software) does this
> Hard drive's firmware is a drive's micro OS, it can manipulate data
> on the disk as it pleases. The only way to protect privacy of the
> data is to write it already encrypted, so it still can be mangled
> and become unusable, but privacy will be kept. But see below about
> DMA.
>
Of course, as I stated you have to bootstrap the crypto from the
motherboard EEPROM chip.
>> One way is to use a blob-free coreboot IOMMU supporting board and
>> bootstrap the crypto/kernel off of the board firmware EEPROM chip to
>> load the initial kernel thus no plaintext touches the disk and thus
>> nothing can mess with it.
>>
>> The IOMMU (theoretically) protects the CPU and memory from rogue
>> devices, such as the hard drive.
> No. Any DMA capable device can bypass IOMMU. IOMMU was not
> designed to protect OS from device.
That isn't true, it was designed for exactly that and of course for
assigning devices to VM's.

I get an AMD-Vi IOMMU IO_PAGE_FAULT alert in dmesg whenever a device
tries to do something it shouldn't and the remapping hardware blocks it.

In linux the kernel/drivers configure which memory locations the devices
are allowed to access.
>> In terms of ethics IBM *for now* is a way better company than Intel/AMD,
>> their POWER servers are owner controlled as there isn't any boot
>> guard/secure boot/management engine/platform "security" processor (amd's
>> ME) to stop you from re-writing the firmware as you please. They also
>> have an getting-there-almost-reasonable open source effort (OpenPOWER)
> Indeed they are. But that boxes are quite expensive and hard to get.
Hard to get? You can buy them from IBM's website like any other computer.
http://www-03.ibm.com/systems/power/hardware/linux-lc.html

If you call them you may get a better price, but a credit card, 5
minutes (and $4.5K) will get you an entry level POWER8 server (although
the almost open source firmware "Firestone" model costs around 10K) If
you want a Palmetto you can get one for around $3K.
They are a good deal vs intel/amd when it comes to performance/price,
and of course the security and owner control aspects are absolutely swell.

If you insert a graphics card you could use one as a workstation.
Re: SHA-1 has just been broken [ In reply to ]
On Thu, 2 Mar 2017 19:04:06 -0500 Rich Freeman wrote:
> On Thu, Mar 2, 2017 at 6:26 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
> > On Thu, 2 Mar 2017 03:42:24 -0500 Taiidan@gmx.com wrote:
> >>
> >> The IOMMU (theoretically) protects the CPU and memory from rogue
> >> devices, such as the hard drive.
> >
> > No. Any DMA capable device can bypass IOMMU. IOMMU was not
> > designed to protect OS from device.
> >
>
> Huh? I thought protection against DMA attacks was half the reason for
> an IOMMU in the first place.
>
> https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit

Even the page you cited contains:
``Some units also provide memory protection from faulty or
malicious devices.''

Please note the word "some" here.

IOMMU was created to restrict OS access to devices (and bring
desired guest VM direct hw access when needed). While it may be
used the other way around — to protect OS from device — it usually
don't work this way, not every IOMMU even supports this.

If we'll look further, IOMMU bypass is a part of normal operation
of many device drivers:
https://lists.gt.net/linux/kernel/365102

Just some real world examples, one can search the web or grep kernel
sources for more:
https://lwn.net/Articles/144207/
https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-February/115239.html

And the funniest stuff: even if IOMMU can be and is configured to
sandbox malicious devices, it can be easily bypassed in most real
world implementations:
https://hal.archives-ouvertes.fr/hal-01419962/document

So relying on IOMMU to protect from malicious devices is even more
naive than relying on SHA1 for crypto integrity needs.

Best regards,
Andrew Savchenko
Re: SHA-1 has just been broken [ In reply to ]
On Fri, 3 Mar 2017 08:48:30 -0500 Taiidan@gmx.com wrote:
> Of course, as I stated you have to bootstrap the crypto from the
> motherboard EEPROM chip.
> >> One way is to use a blob-free coreboot IOMMU supporting board and
> >> bootstrap the crypto/kernel off of the board firmware EEPROM chip to
> >> load the initial kernel thus no plaintext touches the disk and thus
> >> nothing can mess with it.
> >>
> >> The IOMMU (theoretically) protects the CPU and memory from rogue
> >> devices, such as the hard drive.
> > No. Any DMA capable device can bypass IOMMU. IOMMU was not
> > designed to protect OS from device.
> That isn't true, it was designed for exactly that and of course for
> assigning devices to VM's.
>
> I get an AMD-Vi IOMMU IO_PAGE_FAULT alert in dmesg whenever a device
> tries to do something it shouldn't and the remapping hardware blocks it.
>
> In linux the kernel/drivers configure which memory locations the devices
> are allowed to access.

This can be easily bypassed. See my reply to Rich in this thread.
It may protect you from accidental errors, it will not protect you
from malicious action.

> >> In terms of ethics IBM *for now* is a way better company than Intel/AMD,
> >> their POWER servers are owner controlled as there isn't any boot
> >> guard/secure boot/management engine/platform "security" processor (amd's
> >> ME) to stop you from re-writing the firmware as you please. They also
> >> have an getting-there-almost-reasonable open source effort (OpenPOWER)
> > Indeed they are. But that boxes are quite expensive and hard to get.
> Hard to get? You can buy them from IBM's website like any other computer.
> http://www-03.ibm.com/systems/power/hardware/linux-lc.html

There is no way to import them into my country now. In a year or
two maybe, but not now :/

Best regards,
Andrew Savchenko
Re: SHA-1 has just been broken [ In reply to ]
On Mon, Mar 6, 2017 at 2:59 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
> On Thu, 2 Mar 2017 19:04:06 -0500 Rich Freeman wrote:
>>
>> Huh? I thought protection against DMA attacks was half the reason for
>> an IOMMU in the first place.
>>
>> https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit
>
> Even the page you cited contains:
> ``Some units also provide memory protection from faulty or
> malicious devices.''
>
> Please note the word "some" here.
>
> IOMMU was created to restrict OS access to devices (and bring
> desired guest VM direct hw access when needed). While it may be
> used the other way around — to protect OS from device — it usually
> don't work this way, not every IOMMU even supports this.

How can it be possible to bring VM guests direct hw access without
providing protection of the OS from devices?

They use the same mechanism. The driver in the VM tells the card to
write to address XYZ, not knowing that address XYZ in the guest is
different from address XYZ in the host. The host programs the IOMMU
to remap the device access to the correct address. The same mechanism
would let the host remap device DMA to anywhere, or nowhere.

Restricting OS access to devices seems odd unless you're talking about
something like a phone with a second protected CPU. I imagine most
CPUs treat IO access as a privileged operation, and certainly x86
does. So, if a process attempts to write to an IO port it will be
interrupted and the OS can block the access.

>
> If we'll look further, IOMMU bypass is a part of normal operation
> of many device drivers:
> https://lists.gt.net/linux/kernel/365102

Yeah, I wasn't familiar with how poorly it is actually implemented,
and obviously the IOMMU is only as good as its programming.

> And the funniest stuff: even if IOMMU can be and is configured to
> sandbox malicious devices, it can be easily bypassed in most real
> world implementations:
> https://hal.archives-ouvertes.fr/hal-01419962/document

This is just an exploit, and in this case the IOMMU wasn't configured
to sandbox the device at all. If it were configured with minimal
access it certainly wouldn't have write access to the IOMMU
configuration.

> So relying on IOMMU to protect from malicious devices is even more
> naive than relying on SHA1 for crypto integrity needs.

So, I think we're conflating poor implementation with a flawed algorithm.

SHA1 is fundamentally insecure and there is nothing you can do to make
it more secure without making it something other than SHA1.

IOMMU is more of a concept, but I suspect that much of the hardware in
actual use probably works just fine, but nobody spends much time
ensuring that Linux actually secures it. Tighter controls around the
software would make it secure.

This seems a bit like saying that the concept of process memory
protection is flawed because at various points in time some versions
of Linux have had bugs that allow processes to modify memory they
shouldn't be able to modify. The concept is completely sound, but the
implementation is imperfect. I think the main reason that nobody
tolerates sloppy implementation of memory protection is that a lot of
software is written in C and if memory protection doesn't work it is
only a matter of time before the host is crashing, especially for a
software developer. On the other hand, most devices aren't designed
with so many bugs so by the time you're actually plugging cards into
PCs they're not going to be randomly accessing RAM, and it is a lot
harder to get a device to write to random RAM locations than it is to
have a pointer error in your C code unless you're actually developing
a device driver (and if you have a bug in a device driver you could
very well have programmed the IOMMU to let the device write to the
wrong RAM anyway depending on where the error lies).

But, sure, I'm perfectly happy to accept your assertion that device
drivers today tend to open gaping holes in the IOMMU making their
security unreliable. Linux namespaces are in a similar state,
eventually they should become secure but right now the sense is that
they have exploitable flaws.

--
Rich