sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage
- From: Thomas Orgis <thomas-forum AT orgis.org>
- To: sm-discuss AT lists.ibiblio.org
- Subject: Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage
- Date: Sat, 12 Sep 2015 10:29:19 +0200
Am Fri, 11 Sep 2015 12:56:23 -0700
schrieb Eric Sandall <eric AT sandall.us>:
> Git itself protects us
> from out-of-process modifications.
Could you elaborate on that? For sure, someone with root access to the
hosting machine can fake any commit desired by manipulating the
repository on disk? Only the commit data itself is protected against
modification by a hash sum.
I see that this line of thinking takes you quickly towards "Downloading
and running software from THE INTERNET?!! Are you nuts?", but the
circle of people I have to blindly trust (or be able to read many
thousand lines per code really quick) widens with the move.
Perhaps we do need to put a process in place where at least
two people need to agree on a commit before it goes into the stable
(-rc) branch? Hosting our distro stuff besides git (in case we don't
just go for the "Why release? Just let people download a tag from git."
thing that's getting popular) means that we need some kind of actual
quality control before things are put into tarballs and ISOs. This
would mean to actually look at the changes, not just check if things
still build.
Will there be two stages of checking contributions (pull request, later
before merging into branches leading to a release)? I guess the
branching would need to happen on gitlab, too? So, there's no real
sense in inserting a barrier of trust between that and grimoire tarballs.
Or is Vlad willing to read through a detailed diff from the last
tarball, including checking changed source files?
Running a machine straight from git/test grimoire, which is the only
option still, for a non-server machine, will be less of a good idea
with less control of us over the entry point.
Of course you face dangers from any download from THE INTERNET (see
above), but the SMGL grimoire (and sorcery, don't forget that) controls
my whole installation. All of my data on my SMGL-running computers is
in the hands of those who control the repository.
You see where taking professional paranoia seriously, personally, is
taking all the fun out of life? For businesses, it's simple, they have
contracts and can sue people, every loss is just a monetary loss in the
end. You still got your life (although you might be poor and don't
value it much). When I loose control over my digital life, that's a
different impact. I hate to sound that crazy, but I tend to think
things through and that's where I end up when not stopping inside the
comfort zone.
As I said, I can't and won't stop SMGL from making that move, I'm just
re-evaluating my take on this whole privacy, security, and data safety
thing. I wonder if I really should bother encrypting personal data with
software I didn't completely write myself, on hardware I didn't build …
> I personally have enjoyed GitHub and
> the ability that provides for forking and merging with others, even from
> my phone while I'm traveling. :)
Now that just sounds NSFW. Hm, on multiple levels, even;-)
> 3. Our SCM is now in a "cloud" and less prone to a single point of
> failure (SPoF), though failures will still occur.
Well, had I some SCM repositories of mine hosted on sf.net in the past,
I'd have had a lot less uptime than I had with my little private server
box. Of course that's a single lucky case. But the bigger services
still tend to have SPoFs, just bigger ones (your converged storage
backend that somebody just hosed, perhaps literally).
Anyhow, I won't argue that a single non-redundant server is more
reliable than a hosting platform. Just being a bit silly and grumpy.
Just being silly would be more fun.
Alrighty then,
Thomas
Attachment:
pgptiDavrgLuW.pgp
Description: Digitale Signatur von OpenPGP
-
[SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage,
David Kowis, 09/05/2015
-
Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage,
Thomas Orgis, 09/06/2015
-
Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage,
David Kowis, 09/06/2015
-
Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage,
Thomas Orgis, 09/11/2015
- Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage, Jaka Kranjc, 09/11/2015
-
Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage,
Jeremy Blosser, 09/11/2015
-
Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage,
Eric Sandall, 09/11/2015
- Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage, David Kowis, 09/11/2015
-
Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage,
Thomas Orgis, 09/12/2015
- Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage, Jeremy Blosser, 09/13/2015
- Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage, Ismael Luceno, 09/29/2015
-
Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage,
Eric Sandall, 09/11/2015
-
Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage,
Thomas Orgis, 09/11/2015
-
Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage,
David Kowis, 09/06/2015
-
Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage,
David Kowis, 09/13/2015
-
Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage,
David Kowis, 09/22/2015
- Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage, David Kowis, 09/27/2015
-
Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage,
David Kowis, 09/22/2015
-
Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage,
Thomas Orgis, 09/06/2015
Archive powered by MHonArc 2.6.24.