From owner-freebsd-current@freebsd.org Mon Oct 7 07:43:09 2019 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EBAB1F9DB4; Mon, 7 Oct 2019 07:43:09 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46mssS5FCtz4PNS; Mon, 7 Oct 2019 07:43:08 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-io1-xd44.google.com with SMTP id c25so26354255iot.12; Mon, 07 Oct 2019 00:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U8VnsNCGQag82DKgQZKjyNayOQ84NuSUYRyOjAwTieE=; b=dDYaF8ndmmZFe4sWKj+/LPaQyknvyEvvoJ6+AZ1HHnJghIrCrhDoWwQA0mORdBKrw9 CJ6cGVkIO12nUMv7s/dUmlIvJGqq73txKNnqJj2TxstvzsgXdNApjcoiwdz+jqOnz5JY 5qZV6vgRFWyC9X48ifnLvf5Zeu9nGOtevhbx60BMuXnTEw8WH2fSm7iv03DofOL4OSSP hJk+m8powgTiBsAVGkT5J/EZvXczxxwvQ/mdc6zNdUbzsLl9NzKoZxN6WDFSt60ggr9T JR17wpeBB9NvzotFwIptHe49ewtG51aJT7uk6/4LVvzVYmLAmK9X0NHgKS89fWuu8rYG EyZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U8VnsNCGQag82DKgQZKjyNayOQ84NuSUYRyOjAwTieE=; b=SIPSfYA/OnBbU//jRd1BUv7pWI5Jpjz/PBtEg79TxhKcW2qXkiCGGYZPM1MbkfLTwf g7t63U7eWPZXxwgiwoKh1aL2K4RWRFCS0taV2JcvRNy8LlKQojSczCWMO7geOmhrJpxJ ZLH+KgXbRo6F2uAA+3qUWsG2zuDsZxqRlODOgw21r8TITzcabx7sxrLzgIlPQ0OvO+JT KKzEZLV24jKXxgooTYoFrZJmal0WmFidMe0VZrjApAfmpbcBlNf0ZD/QlqPpLNJk7f7y K9iI450ggAnRyOTEV8BzwWNVeq2t97mkiSwEXlD4oxriMyy+fVjde51WDHXKvpW5rQlv 9q4w== X-Gm-Message-State: APjAAAU+qsdf7z0loOJs3hU6H/2PCgvu08MaRDpcyPpd/WgcpT9gDcl7 KUeElAAmjHhayaLuW0kCesrDr4lDMIQ2V83Bc7db8ttC X-Google-Smtp-Source: APXvYqw//rlGXkVUEHgQeNG+enBUytlvevfIOd9BlxTlEjm6yg08DIfsaIXn1jv/7qoEvU9zQEBGuHcznUA+pGZ0WLc= X-Received: by 2002:a5e:aa09:: with SMTP id s9mr23738904ioe.22.1570434187286; Mon, 07 Oct 2019 00:43:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:9f01:0:0:0:0:0 with HTTP; Mon, 7 Oct 2019 00:43:06 -0700 (PDT) In-Reply-To: References: From: grarpamp Date: Mon, 7 Oct 2019 03:43:06 -0400 Message-ID: Subject: Re: Git/Mtn for FreeBSD, PGP WoT Sigs, Merkel Hash Tree Based To: freebsd-security@freebsd.org Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 46mssS5FCtz4PNS X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=dDYaF8nd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::d44 as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(0.00)[ip: (2.27), ipnet: 2607:f8b0::/32(-2.55), asn: 15169(-2.15), country: US(-0.05)]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[4.4.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 07:43:10 -0000 On 10/4/19, Igor Mozolevsky wrote: > On Fri, 20 Sep 2019 at 22:01, grarpamp wrote: >> >> For consideration... >> https://lists.freebsd.org/pipermail/freebsd-security/2019-September/010099.html >> >> SVN really may not offer much in the way of native >> internal self authenticating repo to cryptographic levels >> of security against bitrot, transit corruption and repo ops, >> external physical editing, have much signing options, etc. >> Similar to blockchain and ZFS hash merkle-ization, >> signing the repo init and later points tags commits, >> along with full verification toolset, is useful function. > > > > > Isn't UNIX(TM) philosophy that a program should do one thing and do it > well? Just because people can't be bothered to learn to use multiple > tools to do *multiple* tasks on the same dataset, is not a reason, let > alone "the reason," to increase any program complexity to orders of > N^M^K^L so that one "foo checkout" does all the things one wants! Was r353001 cryptosigned so people can verify it with a second standalone multiple tool called "PGP", after the first standalone multiple tool called "repo checkout"? Was it crypto chained back into a crypto history so they could treat it as a secure diff (the function of a third standalone multiple tool "diff a b") instead of as entirely separate (and space wasting set of) unlinked independant assertions / issuances as to a state? How much time does that take over time each time vs perhaps loading signed set of keys into repo client config. Is LOGO and tape better because less complex tool than C and disk. > When crypto invalidates a repo, how would it be different > from seeing non ASCII characters in plain ASCII files, or sudden > refusal to compile > one way or another you'd still need to restore > from BACKUP Backup is separate, and indeed a fine practice to help keep for when all sorts of horrors can happen. > crypto IS NOT a substitute for good data keeping > practices. Who said that it was. However it can be a wrapper of proof / certification / detection / assurance / integrity / test over them... a good thing to have there, as opposed to nothing. > Also, what empirical data do you have for repo bitrot/transit > corruption that is NOT caught by underlying media? Why are people even bothering to sha-2 or sign iso's, or reproducible builds? There is some integrity function there. Else just quit doing those too then. Many sources people can find, just search... https://www.zdnet.com/article/dram-error-rates-nightmare-on-dimm-street/ http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf http://www.cs.toronto.edu/~bianca/papers/ASPLOS2012.pdf https://www.jedec.org/sites/default/files/Barbara_A_summary.pdf https://en.wikipedia.org/wiki/Data_degradation https://en.wikipedia.org/wiki/ECC_memory https://en.wikipedia.org/wiki/Soft_error Already have RowHammer too, who is researching DiskHammer? Yes, there does need to be current baseline studies made in 2020 across all of say Google, Amazon, Facebook global datacenters... fiber, storage, ram, etc. It is surely not zero errors otherwise passed. Then note all the users who do not run any media, memory, and cables capable of detecting and or correcting garbage. And the claims or data, about "checksums / digests / hashes" that fall short of at least 2^128 odds that strong crypto based repositories can provide. Many do not, and should not, accept less as sufficient standards. What is the worth of your data and instructions producted with some software from some repositories from some hops. Though error is only part of entire possible subject, still however... Lower some risks there too by raising some crypto bars. Be sure to expand "external physical editiing" hinted to include malicious, even by both local and remote adversarial actors, and or those acting outside of established practice. Some crypto repositories require additionally compromise of committer and or distribution private key to impart trust downstream, all of which leaves nice audit, instead of just sneaking in a "vi foo.rcs" or binary equivalent. Cryptographic defense in depth, not prayer. [Sorry not sure which is better mail list]