https://gramps-project.org/bugs/view.php?id=8897

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

https://gramps-project.org/bugs/view.php?id=8897

John Ralls-2
Colleagues,

The subject bug reports that Gramps can’t load modules on Macs because regular OpenSSL can’t access the certificate authorities in Keychain. Apple provides a hacked OpenSSL with a way to check certificates in Keychain, but it's full of holes (see http://www.scip.ch/en/?vuldb.12509). It wasn't the toolchain that allowed my laptop to work, it was that it uses the Apple-provided libssl. The version of OpenSSL provided by the 10.5 SDK is of course quite old and so libsoup won't build with it. I've worked around that by providing a more up-to-date openssl, but not with the Apple patches. Those don't compile because the TrustEvaluationAgent is an Apple private framework with no headers.

https://bugs.python.org/issue17128 recognizes the vulnerability and discusses tradeoffs at length. The commits reported at the end only do what I’m doing: Build a private libssl for Python’s use (and using a build path that’s not compatible with the rest of my build).

As an experimental work-around I've obtained the required CA certs, put them in Gramps.app/Contents/Resources/etc/ssl/certs, and hashed them. That fixes the problem, but puts us on the hook for keeping them current.

The other possible work-around is to create an SSLContext with verify=CERT_NONE to disable certificate checking and pass that to urlopen(), which seems to be what Py2 was doing anyway.

Thoughts?

Regards,
John Ralls


------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: https://gramps-project.org/bugs/view.php?id=8897

Tim Lyons
Administrator
Just had a brief read of the topic.

AIUI you could do a release with the certs hashed in Resources as just a new build, without changing the Gramps code, so not a new Gramps version. If so, I suggest doing that for now.

For the next Gramps dot release, (I.e. Minor release), I suggest just disabling certificate checking. There is no appreciable risk, because that was what was done before, and the user could be induced to load any code and execute it anyway.

Tim.
Reply | Threaded
Open this post in threaded view
|

Re: https://gramps-project.org/bugs/view.php?id=8897

John Ralls-2

> On Sep 22, 2015, at 1:09 PM, Tim Lyons <[hidden email]> wrote:
>
> Just had a brief read of the topic.
>
> AIUI you could do a release with the certs hashed in Resources as just a new
> build, without changing the Gramps code, so not a new Gramps version. If so,
> I suggest doing that for now.
>
> For the next Gramps dot release, (I.e. Minor release), I suggest just
> disabling certificate checking. There is no appreciable risk, because that
> was what was done before, and the user could be induced to load any code and
> execute it anyway.
>

Tim,

Unfortunately I have to pass the path to the bundled certs to urlopen(), so there’s a change to the code either way. I’ll just turn off verification.

Regards,
John Ralls


------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: https://gramps-project.org/bugs/view.php?id=8897

Ronan Waide
On 09/22/2015 10:17 PM, John Ralls wrote:

>> On Sep 22, 2015, at 1:09 PM, Tim Lyons <[hidden email]> wrote:
>>
>> Just had a brief read of the topic.
>>
>> AIUI you could do a release with the certs hashed in Resources as just a new
>> build, without changing the Gramps code, so not a new Gramps version. If so,
>> I suggest doing that for now.
>>
>> For the next Gramps dot release, (I.e. Minor release), I suggest just
>> disabling certificate checking. There is no appreciable risk, because that
>> was what was done before, and the user could be induced to load any code and
>> execute it anyway.
>>
> Tim,
>
> Unfortunately I have to pass the path to the bundled certs to urlopen(), so there’s a change to the code either way. I’ll just turn off verification.
>

For what it's worth, I think turning off verification is not the right
approach. Anything I've tried to write here to expand on that reads as
inflammatory, pedantic, or idealistic, and I've decided that the best I
can do is state my opinion for the record.

Cheers,
Waider.

--
[hidden email] / It's about as impersonal as you can get.


------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: https://gramps-project.org/bugs/view.php?id=8897

John Ralls-2

> On Sep 23, 2015, at 1:01 AM, Ronan Waide <[hidden email]> wrote:
>
> On 09/22/2015 10:17 PM, John Ralls wrote:
>>> On Sep 22, 2015, at 1:09 PM, Tim Lyons <[hidden email]> wrote:
>>>
>>> Just had a brief read of the topic.
>>>
>>> AIUI you could do a release with the certs hashed in Resources as just a new
>>> build, without changing the Gramps code, so not a new Gramps version. If so,
>>> I suggest doing that for now.
>>>
>>> For the next Gramps dot release, (I.e. Minor release), I suggest just
>>> disabling certificate checking. There is no appreciable risk, because that
>>> was what was done before, and the user could be induced to load any code and
>>> execute it anyway.
>>>
>> Tim,
>>
>> Unfortunately I have to pass the path to the bundled certs to urlopen(), so there’s a change to the code either way. I’ll just turn off verification.
>>
>
> For what it's worth, I think turning off verification is not the right
> approach. Anything I've tried to write here to expand on that reads as
> inflammatory, pedantic, or idealistic, and I've decided that the best I
> can do is state my opinion for the record.

Inflammatory is best suppressed, but there’s nothing wrong with pedantic or idealistic.

Are you really in favor of including the certificates in the bundle, recognizing the problems that will cause if they get compromised and revoked?

Regards,
John Ralls


------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: https://gramps-project.org/bugs/view.php?id=8897

Ronan Waide
On 09/23/2015 02:49 PM, John Ralls wrote:
> Inflammatory is best suppressed, but there’s nothing wrong with
> pedantic or idealistic. Are you really in favor of including the
> certificates in the bundle, recognizing the problems that will cause
> if they get compromised and revoked? Regards, John Ralls

Yup.

I'm well aware of such issues from my day job. It's not so much being in
favour of including certificate bundles (a pain, but a necessary one in
this case, it seems), more being rather against weakening secure
connections - even if we believe the risk to be low, or that there are
other compromises that might have similar impact. I'd rather see a small
bit of effort put into making the certificate bundle easily upgradeable
in the event of a revocation/compromise (something /all/ vendors would
have to address in any case, including the OS vendor) rather than simply
switching off verification.

Cheers,
Waider.

--
[hidden email] / It's about as impersonal as you can get.


------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: https://gramps-project.org/bugs/view.php?id=8897

John Ralls-2

> On Sep 23, 2015, at 7:52 AM, Ronan Waide <[hidden email]> wrote:
>
> On 09/23/2015 02:49 PM, John Ralls wrote:
>> Inflammatory is best suppressed, but there’s nothing wrong with pedantic or idealistic. Are you really in favor of including the certificates in the bundle, recognizing the problems that will cause if they get compromised and revoked? Regards, John Ralls
>
> Yup.
>
> I'm well aware of such issues from my day job. It's not so much being in favour of including certificate bundles (a pain, but a necessary one in this case, it seems), more being rather against weakening secure connections - even if we believe the risk to be low, or that there are other compromises that might have similar impact. I'd rather see a small bit of effort put into making the certificate bundle easily upgradeable in the event of a revocation/compromise (something /all/ vendors would have to address in any case, including the OS vendor) rather than simply switching off verification.

You can’t go there without acknowledging that overriding the system certificate path raises it’s own set of very serious security concerns, perhaps more serious than not checking github’s certificate chain.

Regards,
John Ralls


------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: https://gramps-project.org/bugs/view.php?id=8897

Ronan Waide
On 09/24/2015 04:41 AM, John Ralls wrote:
> You can’t go there without acknowledging that overriding the system
> certificate path raises it’s own set of very serious security
> concerns, perhaps more serious than not checking github’s certificate
> chain. Regards, John Ralls

It's the difference in ease of compromise. I don't need direct access to
your system to compromise your SSL connections if you're not validating
the certificate chain - there are many and varied approaches to simply
being the man in the middle, and your lack of verification will allow
that to pass unnoticed. If you're trusting a local cert store, then I
would have to compromise that before being able to do anything of
significance to your SSL connections, and if I've got access to do that,
what other access do I already have?

As I said, I want to put my opinion out there. I'm not on the hook to
maintain this or otherwise deal with the risks, so do proceed as you
think best.

cheers,
Waider.

--
[hidden email] / It's about as impersonal as you can get.


------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel