git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans Petter Selasky <hps@selasky.org>
To: rsbecker@nexbridge.com,
	"'brian m. carlson'" <sandals@crustytoothpaste.net>,
	git@vger.kernel.org
Subject: Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1
Date: Mon, 16 Jan 2023 15:01:07 +0100	[thread overview]
Message-ID: <85788356-14b1-6afb-c78c-0ab889bbbb59@selasky.org> (raw)
In-Reply-To: <017901d929a6$ec180f50$c4482df0$@nexbridge.com>

On 1/16/23 13:34, rsbecker@nexbridge.com wrote:
> On January 16, 2023 2:24 AM, Hans Petter Selasky wrote:
>> On 1/15/23 00:59, brian m. carlson wrote:
>>> However, Git is moving in the direction of stronger cryptographic
>>> algorithms, rather than insecure hashing algorithms.  I don't think
>>> your proposal is a good idea, nor do I think it's likely to be adopted.
>>
>> I disagree. There is no need for signing in a version control system. It just makes it
>> harder to change things, like the right-to-repair. In my eyes there is a high chance
>> of abuse, by vendors that do no want others to flash or edit their device
>> firmwares.
> 

Hi,

> The two matters are completely isolated and distinct. In the OpenSource community, anyone typically has the right to modify. Please refer to the GPLv3, ECLIPSE, and MIT licenses for example. Those are the governing documents that permit modification and define intellectual property rights. Please consult those licenses with regards to right-to-repair statements that have no legal bearing on git or any other GPL-governed software product. In my view, the issue raised is a red herring that keeps getting brought up, which does not contribute positively to this request's discussion, but would presumably would increase the hit rate on web searches, to which this reply unfortunately contributes.

The use of cryptographic hash tags, allows one party to stay in control 
of and monetize a project, actually by doing nothing more than 
rebranding an existing product.

> The assertion of no need for signing can apply to a centralized version control system, like SVN, because users are authenticated centrally, and the contribution can be made definitive without a separate signature, providing no one with root authority on the server hacks the repository. In the architecture of a distributed version control system (specifically git for this discussion), there is no evidence of origin of changes because the commit identity is cooperative rather than being enforced by a central authority and hacking the repository by root is detectible. The assertion of signing as abuse of rights is also an opinion that, so far, has no supporting evidence given. Perhaps a paper in a refereed journal might give this position some credibility.

 From what I've read the GPLv3 goes pretty far to also provide flashing 
rights for software, but what use is that, when flashing the unsigned 
software on your Samsung phone, for example, some fuse breaks in the 
hardware, and then you can no longer use certain apps on your phone?

> 
> My point is that signing is critical in a DVCS and a major function point used by DevOps architects for adopting git in new organizations. In the regulated world, FinTech, FDA, Aviation, etc., signing contributes to the evidence of origin of changes required by PCI and SWIFT (ref: section 6 in each regulation). Without signed tags (which the establishes the change origins for releases for production use), deployment becomes less certain and less acceptable to the audit community with whom I interact on a regular basis.
> 

It's very clear to me, that supporting signing straight off the VCS, 
will not help the opensource and right-to-repair community at all. It's 
just ripe for abuse, like I say.

Hacking is prevented by using a secure copy mechanism between the 
servers, which you can upgrade separately. You already see the problem, 
SHA-1 is not good enough to prevent hacking. Why not just separate the 
hacking preventing measures and the needs of a good VCS?

--HPS

  reply	other threads:[~2023-01-16 14:01 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-13 13:23 Gitorious should use CRC128 / 256 / 512 instead of SHA-1 Hans Petter Selasky
2023-01-14 23:59 ` brian m. carlson
2023-01-15  3:14   ` Junio C Hamano
2023-01-15 10:09   ` demerphq
2023-01-16  7:21   ` Hans Petter Selasky
2023-01-16  7:23   ` Hans Petter Selasky
2023-01-16 12:34     ` rsbecker
2023-01-16 14:01       ` Hans Petter Selasky [this message]
2023-01-16 15:06         ` Junio C Hamano
2023-01-15 13:53 ` Michal Suchánek
2023-01-16  7:17   ` Hans Petter Selasky
2023-01-16  9:13     ` Michal Suchánek
2023-01-16  9:55       ` Hans Petter Selasky
2023-01-16 12:31         ` rsbecker
2023-01-16 14:10           ` Hans Petter Selasky
2023-01-16 19:08         ` Michal Suchánek
  -- strict thread matches above, loose matches on Subject: below --
2023-01-13 12:59 Hans Petter Selasky
2023-01-13 13:30 ` Konstantin Khomoutov
2023-01-13 13:39   ` Hans Petter Selasky
2023-01-13 14:21     ` rsbecker
2023-01-13 14:42       ` Hans Petter Selasky
2023-01-13 15:45         ` Konstantin Ryabitsev
2023-01-13 15:50           ` Hans Petter Selasky
2023-01-13 15:56             ` rsbecker
2023-01-13 16:02               ` Hans Petter Selasky
2023-01-13 15:54           ` Hans Petter Selasky
2023-01-13 16:02             ` Konstantin Ryabitsev
2023-01-13 16:06               ` Hans Petter Selasky
2023-01-13 16:18                 ` Hans Petter Selasky
2023-01-13 16:36                   ` Konstantin Ryabitsev
2023-01-13 16:44                     ` Hans Petter Selasky
2023-01-13 16:49                       ` Konstantin Ryabitsev
2023-01-13 16:51                         ` Hans Petter Selasky
2023-01-13 16:27                 ` Konstantin Ryabitsev
2023-01-13 16:30                   ` Hans Petter Selasky
2023-01-13 16:35                   ` Hans Petter Selasky
2023-01-13 16:41                     ` Konstantin Ryabitsev
2023-01-13 16:45                       ` Hans Petter Selasky
2023-01-13 15:15       ` Hans Petter Selasky
2023-01-13 17:44       ` Philip Oakley
2023-01-13 15:30     ` Konstantin Khomoutov
2023-01-13 15:39     ` Konstantin Ryabitsev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85788356-14b1-6afb-c78c-0ab889bbbb59@selasky.org \
    --to=hps@selasky.org \
    --cc=git@vger.kernel.org \
    --cc=rsbecker@nexbridge.com \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).