Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Gitlab.com as the primary git entry point for Sourcemage

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • 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




Archive powered by MHonArc 2.6.24.

Top of Page