This is not about this incident, but about why major opensource
projects need to be using a repository that has traceable, verifiable,
built-in cryptographic authentication.
Any of hundreds of committer and admin accounts could be compromised
with the attacker silently editing the repo. The same applies to
any of those accounts going rogue. Backtrack diffing from a breach
to 'see what changed' is not the ideal option. You really need to
be using a strong repo so that any attack on it is null from the
start. Another problem is bit rot wherever it may occur... disk,
hardware, the wire, EMP and other systems.
As it is now, we have no way to verify that what we get on pressed
CD's, ISO's, FTP sites, torrents, etc is strongly linked back to
the original repo. Signing over a hash of the ISO is *not* the same
as including the strong repo hash (commit) that was used to build
the release and then signing over that and the ISO. We can't know
that our local repository updates match the master. ports.tar.gz
has no authentication either. Nor does anything in the entire project
that originates from the current SVN/CVS repo... webpages, docs,
tools, source tarballs, etc. The FTP packages aren't signed, and
there are weak MD5's used in various parts of the install/package
tools, mirrors, etc. We can't trade hashes amongst people. It's all
just a bunch of random bits that someone may or may not have signed
over. And even if signed they still wouldn't be strongly linked
back to the master repo. Having such a disconnect at the root of
everything you do is simply not good practice these days.
And these days, Git is what people and projects are moving to, and
its rate of adoption and prevalence have essentially won out over
all the rest in the new 'revision control 2.0 world'. And knowing
Git is now more or less essential if you want to participate in a
wide variety of community development, ref: github, etc.
The FreeBSD project needs to be providing both itself, and its users
and benefactors with verifiable assurance that its repository, and
any copies and derived products, are authentic and intact.
Don't argue against such a repository feature, or the cost to move,
or bury your head in the sand by saying it could never happen to us...
Take this as a real opportunity to lead amongst the major opensource
projects like Linux, and among the BSD's (like DragonFly has), and
move to Git.
Once the root is fixed, you can push out secure distribution and
update models from there. It all starts at the root and can't be
done without it.
http://git-scm.com/about/info-assurance The data model that Git uses ensures the cryptographic integrity
of every bit of your project. Every file and commit is checksummed
and retrieved by its checksum when checked back out. It's impossible
to get anything out of Git other than the exact bits you put in.
It is also impossible to change any file, date, commit message,
or any other data in a Git repository without changing the IDs of
everything after it. This means that if you have a commit ID, you
can be assured not only that your project is exactly the same as
when it was committed, but that nothing in its history was changed.
https://en.wikipedia.org/wiki/Git_(software)
The Git history is stored in such a way that the id of a particular
revision (a "commit" in Git terms) depends upon the complete
development history leading up to that commit. Once it is published,
it is not possible to change the old versions without it being
noticed. The structure is similar to a hash tree, but with additional
data at the nodes as well as the leaves.
> This is not about this incident, but about why major opensource > projects need to be using a repository that has traceable, verifiable, > built-in cryptographic authentication.
> Any of hundreds of committer and admin accounts could be compromised > with the attacker silently editing the repo. The same applies to > any of those accounts going rogue. Backtrack diffing from a breach > to 'see what changed' is not the ideal option. You really need to > be using a strong repo so that any attack on it is null from the > start. Another problem is bit rot wherever it may occur... disk, > hardware, the wire, EMP and other systems.
> As it is now, we have no way to verify that what we get on pressed > CD's, ISO's, FTP sites, torrents, etc is strongly linked back to > the original repo. Signing over a hash of the ISO is *not* the same > as including the strong repo hash (commit) that was used to build > the release and then signing over that and the ISO. We can't know > that our local repository updates match the master. ports.tar.gz > has no authentication either. Nor does anything in the entire project > that originates from the current SVN/CVS repo... webpages, docs, > tools, source tarballs, etc. The FTP packages aren't signed, and > there are weak MD5's used in various parts of the install/package > tools, mirrors, etc. We can't trade hashes amongst people. It's all > just a bunch of random bits that someone may or may not have signed > over. And even if signed they still wouldn't be strongly linked > back to the master repo. Having such a disconnect at the root of > everything you do is simply not good practice these days.
> And these days, Git is what people and projects are moving to, and > its rate of adoption and prevalence have essentially won out over > all the rest in the new 'revision control 2.0 world'. And knowing > Git is now more or less essential if you want to participate in a > wide variety of community development, ref: github, etc.
> The FreeBSD project needs to be providing both itself, and its users > and benefactors with verifiable assurance that its repository, and > any copies and derived products, are authentic and intact.
> Don't argue against such a repository feature, or the cost to move, > or bury your head in the sand by saying it could never happen to us...
> Take this as a real opportunity to lead amongst the major opensource > projects like Linux, and among the BSD's (like DragonFly has), and > move to Git.
> Once the root is fixed, you can push out secure distribution and > update models from there. It all starts at the root and can't be > done without it.
> http://git-scm.com/about/info-assurance > The data model that Git uses ensures the cryptographic integrity > of every bit of your project. Every file and commit is checksummed > and retrieved by its checksum when checked back out. It's impossible > to get anything out of Git other than the exact bits you put in. > It is also impossible to change any file, date, commit message, > or any other data in a Git repository without changing the IDs of > everything after it. This means that if you have a commit ID, you > can be assured not only that your project is exactly the same as > when it was committed, but that nothing in its history was changed.
> https://en.wikipedia.org/wiki/Git_(software) > The Git history is stored in such a way that the id of a particular > revision (a "commit" in Git terms) depends upon the complete > development history leading up to that commit. Once it is published, > it is not possible to change the old versions without it being > noticed. The structure is similar to a hash tree, but with additional > data at the nodes as well as the leaves.
There's a git repository. It's public. You can look at what goes into
the FreeBSD git clone to get your assurance that things aren't being
snuck in. People are using it, right now.
Honestly, I'd rather see subversion grow this kind of cryptographic
signing of each commit in the short term then migrate everyone over to
git.
Those who want to use git can use it, right now. Honest.
>> joerg_wun...@uriah.heep.sax.de
> You don't even have a name
Your domain indicates Germany, please have a chat with CCC.de about
the various good uses for nyms. And consult your library for some
fine historical use cases. If that's counter to your beliefs, you
are free to show us the way and post all your personal infos to the
list.
> spamming a large number of FreeBSD mailinglists with your advocacy?
This topic would benefit from the review and involvement of users
(questions), committers (hackers), security (security), and
distribution (hubs).
> --
> Never trust an operating system you don't have sources for. ;-)
As well summarized by this (your signature) ... sources you can't
verify to the master are, also, sources you can't trust.
How will what help Linux? Please quote a relevant snippet instead
of the entire message.
Seems pretty clear from the above link that having hashes/crypto
as an intrinsic feature of the SCM tool does in fact help Linux.
If you're asking about distribution of things traceable back to the
master repo, at least your security officer can sign the initial
repository commit and then include the various distribution keys
and subsequent updates, signed tags, etc in the repo.
>> utis...@gmail.com
> Yes, but git doesn't work with our workflow.
There's usually a larger than head sized sandbox near everyone's
local neighborhood. Will people elect to visit it, or to learn,
grow, and change for the better? Prioe workflow is often forced by
and derived from the tools being used. Different tools could enable
different, more useful workflows. SVN required workflow change from
CVS, people managed just fine.
> It's been discussed several times
I will look for these. Can you point to a couple main threads?
> [git] ... is GPL btw
FreeBSD does not include this sort-of-BSD licensed SCM tool in its
base either...
So it seems license is not an obstacle to inclusion, and certainly
not the use via ports, of any particular SCM with the FreeBSD
project.
>> rsimmo...@gmail.com
> https://github.com/freebsd/ >> adr...@freebsd.org
> You can look at what goes into the FreeBSD Git clone to get your
> assurance that things aren't being snuck in.
The same could be said for the CVS clone. Again...
Any copy of something that is itself not verifiable provides no
such assurance.
> Those who want to use git can use it, right now. Honest.
Yes, Git does seem to me to be leading the other distributed, hash
based, SCM tools such as Hg. Thus Git is suggested. Yes, Git would
fill the purpose. I only suggest Git, as to some other choices that
use hashes (as usual, please verify with current releases)...
https://en.wikipedia.org/wiki/Comparison_of_revision_control_software
But this is not really about using Git in particular...
These replies are all dodging around the base issue raised...
- That FreeBSD has no verifiable source repo
- Which is not only a problem for the repo itself, but for everything
attempted to be spawned downstream off of that root (no verifiable
distribution system/tools distributing that repo, etc).
Sorry to reply to these sorts of replies this way, but please, this
isn't a troll or a shed. No need to do that around the issue raised.
Hash [ :-) ] it out and solve it. Why wait for a costlier breach?
Why not provide the assurance beforehand? No better time than now.
Yes, another good link outlining the issue.
_______________________________________________
freebsd-questi...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
On Sun, 18 Nov 2012 00:59:54 -0500, grarpamp wrote:
> > Never trust an operating system you don't have sources for. ;-)
> As well summarized by this (your signature) ... sources you can't
> verify to the master are, also, sources you can't trust.
Unless. of couse, you are able to "use the source Luke" and
spot malicious portions by yourself. This of course is usually
possible to subsets only, and mostly to the gurus of our guild.
The "ordinary user" won't be able to do this.
> How will what help Linux? Please quote a relevant snippet instead
> of the entire message.
> Seems pretty clear from the above link that having hashes/crypto
> as an intrinsic feature of the SCM tool does in fact help Linux.
The article's headline is "kernel.org compromised", and the
significant part (as of August 2011!) is:
Earlier this month, a number of servers in the kernel.org
infrastructure were compromised. We discovered this August
28th. While we currently believe that the source code
repositories were unaffected, we are in the process of
verifying this and taking steps to enhance security across
the kernel.org infrastructure.
However, this is a Linux problem, not a FreeBSD one, regarding
repository infrastructure.
> >> utis...@gmail.com
> > Yes, but git doesn't work with our workflow.
> There's usually a larger than head sized sandbox near everyone's
> local neighborhood. Will people elect to visit it, or to learn,
> grow, and change for the better?
In many contexts, "better" _depends_.
> Prioe workflow is often forced by
> and derived from the tools being used.
That is _one_ (valid!) way to see it. Another way is that tools
will be chosen according to established workflows, or tools will
adapt those workflows to better support them.
> Different tools could enable
> different, more useful workflows. SVN required workflow change from
> CVS, people managed just fine.
If the required programs will be integrated in the OS, accompanied
by proper documentation, and the backend infrastructures being
instantiated, up and running, I don't see a big problem. Unlike
in other "OS countries", FreeBSD people are able to adapt to new
methods and tools.
> So it seems license is not an obstacle to inclusion, and certainly
> not the use via ports, of any particular SCM with the FreeBSD
> project.
As far as I know, FreeBSD team puts much work into getting the
OS into a "BSD license only" state, making it more appealing to
commercial use where the (often so called) "rape me license"
BSDL is very welcome.
But as for "being part of the OS installation", you are right:
Whatever tool will be required (or at least suggested) for the
purpose of managing "CVS-like" functionality for sources and
the ports collection should be part of the basic installation.
That's why "pkg_add -r cvsup-without-gui" (if I remember correctly)
has been the way in the past, but then, a rewrite called csup
became part of the default installation, so you could use the
known cvs command _and_ have a nice integration with system
functionality, like entries in /etc/make.conf and configuration
files for _how_ to update sources, ports, documentation and
so on (e. g. in /etc/sup, with /usr/share/examples/cvsup/ as
examples), so "make update" would do whatever you wanted.
Exactly that kind of productive (!) behaviour is what I would
expect (or at least wish) for any replacement of CVS, be it
SVN or Git.
> Sorry to reply to these sorts of replies this way, but please, this
> isn't a troll or a shed. No need to do that around the issue raised.
> Hash [ :-) ] it out and solve it.
With some salt, please. :-)
-- Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
_______________________________________________
freebsd-questi...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Hello, Adrian. You wrote 18 ноября 2012 г., 8:55:54:
AC> There's a git repository. It's public. You can look at what goes into AC> the FreeBSD git clone to get your assurance that things aren't being AC> snuck in. People are using it, right now. But commits in this repo aren't signed by developers../
-- // Black Lion AKA Lev Serebryakov <l...@FreeBSD.org>
On Sun, Nov 18, 2012 at 1:57 AM, Garrett Wollman <woll...@bimajority.org> wrote:
>> the various good uses for nyms.
> There are no such uses on the FreeBSD mailing-lists; if you wish for
> anyone to pay attention to you, then use a real name. Otherwise,
> FOAD.
> -GAWollman
It appears you have not reviewed the mailing list archives, otherwise you
would have found many such nym holders engaging in good participation.
However I do thank you for your opinion, and for your delightful and
unwarranted private abuse. A good day to you indeed, Sir.
_______________________________________________
freebsd-questi...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
On Sun, Nov 18, 2012 at 6:59 AM, grarpamp <grarp...@gmail.com> wrote:
>>> joerg_wun...@uriah.heep.sax.de
>> You don't even have a name
> Your domain indicates Germany, please have a chat with CCC.de about
> the various good uses for nyms. And consult your library for some
> fine historical use cases. If that's counter to your beliefs, you
> are free to show us the way and post all your personal infos to the
> list.
Uh-oh grarpamp, I hope you realize whom you're trying to lecture here!
Joerg Wunsch is a highly appreciated long-time FreeBSD contributor and
was member of the Core Team for a long time (I met him in person in
the 90-ies and he's a very kind person). I wouldn't dismiss his advice
lightly, unless I had a very good reason.
>> grarpamp
>> the various good uses for nyms.
> cpgh...@cordula.ws
> I hope you realize whom you're trying to lecture here!
> Joerg Wunsch is a highly appreciated long-time FreeBSD contributor
Of course. No one here has any question as to anyone's FreeBSD
participation. That would be silly :) I merely contest the suggestion
that nyms have little to no utility, that people need moderate their
usage alone in public, and that those using them are somehow lessers.
I won't fail to defend general anti-nym opinion or guidance, particularly
when wafted in this general direction.
> Now, back to our regular programming.
Yes, about this lack of a self-authenticating repo, etc. [1]
It is good to see some discussion forming around it :)
[1] Or whatever it may better be called.
Put another way... we can't yet say, in the strong cryptographic
sense, that anyone has a true copy of the repo. Or that the repo
is itself internally tamper free and/or tamper proof. And so on as
applied down the production and distribution chain. The repo
does face certain risks. And Git appears as if it may be one
way to mitigate them.
_______________________________________________
freebsd-questi...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
-- Sphinx of black quartz, judge my vow.
_______________________________________________
freebsd-questi...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Even if it was BSD licensed, Mercurial has a huge dependency:
Python; and Git is Perl-based. So neither of them is ideal, IMHO.
If at all, we'd need a lean and mean distributed SCM program
like Mercurial or Git, but written in C that we could add to base.
Any volunteers?
> Even if it was BSD licensed, Mercurial has a huge dependency:
> Python; and Git is Perl-based. So neither of them is ideal, IMHO.
> If at all, we'd need a lean and mean distributed SCM program
> like Mercurial or Git, but written in C that we could add to base.
> Any volunteers?
"Mercurial is free software licensed under the terms of the GNU General
Public License Version 2 <http://www.gnu.org/licenses/gpl-2.0.txt> or any
later version."
No one of them above mentions "BSD license" , or "dual license" , etc.
> There's a git repository. It's public. You can look at what goes into
> the FreeBSD git clone to get your assurance that things aren't being
> snuck in. People are using it, right now.
I've always been confused by this. Which source repo is the true source
of truth?
To obtain the FreeBSD source, you can use CVS, SVN, or Git? Do all have
the same level of support? Are they all up to date?
> Honestly, I'd rather see subversion grow this kind of cryptographic
> signing of each commit in the short term then migrate everyone over to
> git.
How much effor would their really be involved, considering your link to
the FreeBSD source repo on github. Converting the repos to me seems
like it would be the bulk of it, and that work is already done. Help me
understand please.
>> I'm not fossil user, but it's BSD licensed in written in C.
>Also, this particular tool bails out on the unix philosophy, with its
>web
>gui, ticket tracker etc. Do one thing. Do it well.
I would argue that git bails on that as well, but that's a different discussion.
Whether or not fossil does "one thing" depends on which "one thing" you pick. If the one thing is "version control", you're right. However "version control" is just one aspect of a larger task that does't have a common name. But if you look at systems designed for managing projects with source, you'll see they universally provide web uis, issue trackers, and wikis. Due you trash IDE's because they provide tools that are useful for doing "software development" instead of limiting themselves to being "text editors"?
That fossil provides all of those things in a single relatively small program is a major win - at least for small projects (which is the fossil target). On the other hand, the fossil project does stay focused on the core task. They will reject a change proposal because it's not part of that task.
That said, much as I like fossil (it's my goto VCS) I don't think it would be a good choice for FreeBSD. We're not a small project - we have people who are willing to devote time to things like an external wiki and isse tracker. Nuts, we have (had?) repos in four different VCSs! Those features in fossil are purposely kept simple since they're meant for doing one thing, not as general-purpose tools for lots of things. The issue tracker doesn't support branching issues, which is liable to cause problems in a large project. The FreeBSD wiki's are used for lots of things other than just project documents. The web ui - well, that's probably useable as is. But that one thing isn't a deal maker.
-- Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
_______________________________________________
freebsd-questi...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
> > I'm not fossil user, but it's BSD licensed in written in C.
> > Baptise Daroussin probably could tell us more about fossil pro and cons.
> This misses one of of the main points raised in the original post. The
> proliferation of git as a revision control system.
> Also, this particular tool bails out on the unix philosophy, with its web
> gui, ticket tracker etc. Do one thing. Do it well.
Look at the internal of fossil and how things are done in fossil and you would
understand that the last sentence is totally wrong.
Fossil has really nice features that could nicely fits with FreeBSD workflows
and greatly improves it.
It has most of the new shiny feature everyone can expect from a dvcs, but it
also has it drawbacks:
The converted repositories (I did convert docs, src and ports) with full history
kept: branches, tags, etc. is huge and the first clone would be painful to do.
On the other side you have multiple working copies open on the same clone which
is really nice.
Some of the operations can be slow, Jörg Sonnenberger wrote an analysis about
this one the fossil wiki, but don't remember the link sorry.
From my testing, apart from the do we really need a new scm question? I am a big
fan of fossil and find it easier and cleaner than all the other scm I know, I
use git for pkgng and other projects, I use a lot mercurial on some other area,
and fossil remains my favorite :). But I really don't think it could fit
FreeBSD's requirements as it is now. but there are lots of room of improvements.
The learning curve to fossil is probably really easy.
On of the last thing is that fossil lacks keyword expansion.
That said I'm happy with svn on FreeBSD, I still from time to time do conversion
of out different tree to fossil for fun, but no more and I won't advocate for
any vcs change.
grarpamp <grarp...@gmail.com> writes: > Any of hundreds of committer and admin accounts could be compromised > with the attacker silently editing the repo.
FUD. Committer accounts don't have direct access to the repo.
