Public SourceMage Discussion List

["Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>]

On Aug 30, Sergey A. Lipnevich [sergey AT optimaltec.com] wrote:
> Quoting Eric Sandall <eric AT sandall.us>:
> 
> > We're not asking you to sign your soul away. I cannot see how you are
> > completely missing the point of what we're saying. You are /not/
> > signing tarballs saying that you have audited the code (unless you
> > have, then you can say that), nor that you guarantee this tarball
> > won't break your computer, nor that this tarball has no viruses,
> > trojans, worms, wife beaters, etc. in it, nor that this tarball has no
> > bugs, nor many other things. The only thing the GPG signatures are for
> > is to replace the dependency on specific hashsums (md5sum, sha1sum,
> > etc.) and to allow for trusting the vendor's as much as we currently
> > trust them (I don't recall anyone doing audits of source code of any
> > packages for SMGL and no one complained that signing (yes, it's
> > technically a signature) with the md5sum said that you had done that).
> 
> Let me explain it differently because we keep walking around the same 
> issue.

I'm pretty sure we're not walking around it at all.  We understand your
argument, but you're factually wrong in your understanding of cryptographic
signatures, and possibly even paper signatures.

> The users don't care no matter how you describe your use of signatures. I
> as a user don't care how for example Apache Software Foundation describes
> their use of signatures. When I, as a user, see a signature, I assume
> that they vouch for contents of file, not just this file's integrity.
> That's how I treat signatures. Tell me if I'm wrong, but you better have
> a good reason for it.

You are wrong.  We already provided URLs documenting what digital
signatures do and don't mean, please take a look at them if you haven't
yet.

> Even more so, Apache for example doesn't have any explanation. I tried
> searching the site and I can't find a policy. Please find me a policy on
> some major OSS vendor site that says: GPG signatures are used for
> integrity only and do *not* mean non-repudiation and authenticity *of the
> code*.

You have this backwards.  The onus to assign extra meaning to a signature
is always on the person wanting to assign that meaning, not on the people
wanting to stick to the implicit meaning.  Digital (and paper) signatures
on their own always only have their implicit meaning: authenticity of the
signer, integrity of transimission (for a non-digital signature this would
usually be a seal of some kind), and non-repudiation (again, *of the
signer*, not the contents).  No signature of any kind ever means "I've read
all of this and there is nothing hazardous in it" by itself.  That has to
be attached to the signature for it to be there.  You may choose to believe
that a tarball with a verified signature will not harm your system because
of what you know about the signer/developer and his or her own coding and
source security practices, but there is no guarantee of that unless they
explicitly give you one.  If you run code someone provides and it eats your
system you will not be able to use a digital signature to go after them for
liability absent an explicit guarantee from them that that wouldn't happen.

In point of fact, the vast majority of FLOSS software explicitly disclaims
any such liability.  You asked for a URL, here is one:

http://www.apache.org/licenses/LICENSE-2.0

That is the apache software license, version 2, which covers apache 2 and
includes in part:

==================================================
7. Disclaimer of Warranty. Unless required by applicable law or agreed to
in writing, Licensor provides the Work (and each Contributor provides its
Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied, including, without limitation, any
warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or
FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for
determining the appropriateness of using or redistributing the Work and
assume any risks associated with Your exercise of permissions under this
License.

8. Limitation of Liability. In no event and under no legal theory, whether
in tort (including negligence), contract, or otherwise, unless required by
applicable law (such as deliberate and grossly negligent acts) or agreed to
in writing, shall any Contributor be liable to You for damages, including
any direct, indirect, special, incidental, or consequential damages of any
character arising as a result of this License or out of the use or
inability to use the Work (including but not limited to damages for loss of
goodwill, work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor has been
advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability. While redistributing the
Work or Derivative Works thereof, You may choose to offer, and charge a fee
for, acceptance of support, warranty, indemnity, or other liability
obligations and/or rights consistent with this License. However, in
accepting such obligations, You may act only on Your own behalf and on Your
sole responsibility, not on behalf of any other Contributor, and only if
You agree to indemnify, defend, and hold each Contributor harmless for any
liability incurred by, or claims asserted against, such Contributor by
reason of your accepting any such warranty or additional liability. 
==================================================

That is pretty clear that their software can do whatever it wants to your
system and it's not their fault.  If you believe that them providing a
digital signature with their tarball negates any of that and in fact exends
a "secure-code" guarantee from them to you then I'm sorry but you're wrong
and in for a rude awakening if something ever does trash your system from a
signed tarball.

Attachment: pgpkkxEIXm481.pgp
Description: PGP signature