[python-committers] New Authenticode certificate

M.-A. Lemburg mal at egenix.com
Wed Feb 17 12:03:36 EST 2016 

On 16.02.2016 23:45, Jeff Hardy wrote:
> On Wed, Feb 10, 2016 at 12:40 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> 
>> On 09.02.2016 22:40, Steve Dower wrote:
>>> On 09Feb2016 1030, M.-A. Lemburg wrote:
>>>> On 09.02.2016 18:41, Jeff Hardy wrote:
>>>>> On Mon, Feb 8, 2016 at 12:34 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>>>>>
>>>>>> To everyone: We now have a PSF code signing certificate.
>>>>>>
>>>>>> I have sent the certificate to Steve for use in the Windows
>>>>>> installers. If other developers need to create signed
>>>>>> installers/code for Python, please let me know.
>>>>>>
>>>>>
>>>>> Hi Marc-Andre,
>>>>> Would it be possible to use it for IronPython as well?
>>>>
>>>> I don't know. Steve is using it as Authenticode certificate,
>>>>
>>>> [SNIP]
>>>>
>>>> It will certainly work for signing executables and msi
>>>> installers.
>>>>
>>>> Perhaps Steve can help with this.
>>
> 
> Yes, it would be signing the IronPython .exe's, MSI, and possibly NuGet
> packages (although that part of the ecosystem is in flux and I have no idea
> what's going on right now).
> 
> 
>>>>
>>>
>>> There are three aspects to this: technical, political and security.
>>>
>>> Technically, yes IronPython could absolutely be signed with the same
>> certificate.
>>>
>>> Politically, it requires the PSF to be willing to put their name to the
>> safety of the signed
>>> binaries and installers. Essentially, if/when something bad is done with
>> or via something signed by
>>> the PSF, there is an implied responsibility (no idea how legally
>> enforceable it is). I am not in a
>>> position to say whether or not this is okay for IronPython.
>>
>> Regardless of politics (the PSF wants to help where ever we can),
>> we may only sign code with the PSF code signing certificate which
>> the PSF has a right to distribute.
>>
>> I originally was under the impression that we do, but now that I
>> wanted to check, I'm having trouble finding the copyright owners
>> of the code.
>>
>> The license is the Apache license (but without copyright holder
>> information), and the stdlib is part of the installers (which the
>> PSF has distribution rights to), but the IronPython runtime itself
>> only says: "Copyright (c) IronPython Team", so it's not clear what
>> distribution rights the PSF would have.
>>
> 
> We deliberately didn't so copyright assignment at the start to avoid
> dealing with the MS lawyers too much, so the bulk of the code is (c)
> Microsoft, the rest would be whoever wrote it. It's a nice, low-friction
> system, as long as we don't change it. :)
> 
> If we had to move to PSF copyright assignment I'd be OK with it (and I
> doubt other main contributors would have an issue) but the trick would be
> tracking down all other contributors and getting their sign off, and also
> getting MS to sign off on it (although the MS of today would probably be
> more amenable than the MS of 5 years ago).

I can take this up to the PSF board to see whether we'd
want to go through that trouble :-)

One of the reasons Python has the long license stack is that
we've so far avoided trying to cut it down one by one, since
it involves lots of talk not many people really want to go
through or invest time into.

> Alternatively, maybe the *binaries* can be (c) PSF, but the code copyrights
> remain the same as they are. Not sure if that's a thing. Then the PSF would
> have no issues distributing the binaries. I'm pretty sure the Apache
> license is enough to give the PSF (though their representative) permission
> to build binaries from the source and distribute them, but IANAL, etc.

Hmm, you're raising a good point. The Python contrib forms
also license the code using the Apache license (as one of two
possible licenses) to the PSF, without assigning copyright.

The contrib forms give the PSF a permission to relicense the
code, but this wouldn't be necessary here, since we'd just
be distributing the binaries under the same license.

And in the end, object signing just means that *we* used
the code to build the executables, nothing more, so not
even the "(c) PSF" should be necessary.

>>> Security-wise, it is very important to minimize the number of people who
>> have access to the
>>> certificate. Code signed with this certificate is basically given a free
>> pass by most virus scanners
>>> and security software.
>>
>> I don't think that's a true statement. Decent virus scanners
>> will still scan the files for malicious content, even if signed.
>>
>> It's true that minimizing the possible attack surface is always
>> preferred, though.
>>
>>> If we decide to start signing IronPython with the PSF certificate, I'd
>> be most comfortable if I were
>>> doing the builds to avoid sharing the certificate any further than
>> needed. But that isn't going to
>>> scale when all the other interpreters want equal treatment.
>>>
>>> I'm not sure exactly what the cost of the certificate is to the PSF, but
>> it may be an expense
>>> they're willing to take to get separate certs?
>>
>> We can only get one code signing certificate per organization from
>> our certificate provider StartSSL.
>>
> 
> I don't have an issue with Steve building them; the release process is
> pretty much a single make step. It's a mild annoyance for each of us, but
> it would only be for final releases, so only 2-3 times a year at most.

If Steve is fine with this approach, it sounds like a good option.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Feb 17 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
________________________________________________________________________
2016-01-19: Released eGenix pyOpenSSL 0.13.13 ... http://egenix.com/go86

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
                      http://www.malemburg.com/

More information about the python-committers mailing list