[gentoo-dev] News item for review: python-exec package move
Please review the following news item. I would prefer committing it as soon as I get an ACK from all the relevant parties since the issue is hitting users pretty hard. Title: python-exec package move Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2013-xx-xx Revision: 1 News-Item-Format: 1.0 Display-If-Installed: dev-python/python-exec Due to the recent issues which caused dev-python/python-exec:0 being removed prematurely [1], we had to perform an urgent package move. Since we could not use the automatic updates support in portage, users will notice two python-exec packages and possibly blockers. Currently, dev-lang/python-exec is the real package that contains python-exec and that will be used in the future. dev-python/python-exec is kept for compatibility with dependencies in already-installed packages. In the most favorable scenario, the package will be upgraded correctly on your next world update. However, you need to make sure to pass the '--deep' (-D) and '--update' (-u) options to emerge. If you don't want to perform a complete world update, you may as well manually upgrade dev-python/python-exec: emerge -1 dev-python/python-exec This will cause portage to update both python-exec packages and resolve the blockers properly. Please note that if you applied any kind of package-specific modifications to dev-python/python-exec (such as applying keywords through 'package.accept_keywords'), you will need to copy them to dev-lang/python-exec as well. If you applied keywords to dev-python/python-exec in order to unmask Python 3.3 on a stable system, please consider removing the keywords and reading our wiki page that explains how to properly unmask USE flags [2]. We apologize for all the inconveniences. [1]:https://bugs.gentoo.org/show_bug.cgi?id=489440 [2]:https://wiki.gentoo.org/wiki/Python/PYTHON_TARGETS#Unmasking_non-stable_implementation_on_a_stable_system -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Policy-level discussion for minimum versions on dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all... Mozilla had a bug recently ( http://bugs.gentoo.org/show_bug.cgi?id=489838 ) that I think has much wider implications for all packages, and I would like to discuss how to best address this. The synopsis of the situation is that the latest firefox ebuild now depends on icu, specifically icu-50.1 or above. When this version of firefox was added to the tree, the lowest version of icu in the tree was icu-51.0 -- in fact, icu-48 through icu-50 were dropped from the tree about 2 months prior to the new firefox being added. The bug that was filed, is that a user didn't do a full emerge -uDN @world prior to emerging (upgrading?) firefox, and they had icu-49 already installed. Because the firefox dep didn't have a minimum version, portage didn't see upgrading icu as a requirement before firefox emerged. I fully agree with the user and other commenters on the bug, that after --sync'ing a user should be able to 'emerge [-u] firefox' and all necessary dependency updates would be applied. However, it's been a long-standing general practise that if there are no deps in the tree older than what is necessary for a package, that package doesn't need to have a minimum version on the dependency atom. As such, issues similar to this are probably lying in wait all other the place in the tree. To mitigate this, i see three possibilities: 1 - make it clear in documentation for end users that they need to emerge -uDN @world after a --sync, otherwise they may see breakage and if they do it's not a bug when an emerge -uDN @world fixes it. IMO this is not a desirable solution but it best matches what is unofficially required now. 2 - make a policy for developers that they need to add minimum versions on dependency atoms so that their package will trigger dependency updates, for all dependencies that have in the last year (**) had a version in the tree older than what the package needs. This is the most correct solution, but requires all devs to do the work. 3 - change portage behaviour s.t. somehow when resolving dependencies it does not consider installed atoms that are missing from the tree to be valid at satisfying a dependency of a package. This would resolve the issue without dev's as a whole needing to do anything different, but would also have unforseen consequences since this is a major behavioural change for portage's dependency resolution. Thoughts? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlJ6XSIACgkQ2ugaI38ACPAWtgEAsiXy5LmYriPMeRanleI7fqNK faU2TwOpvykeYfEwpqQA/AirKpkPwpSp6tGau1PPjeOIGUuz6dZgnL8KkZ/J9JEa =VUYT -END PGP SIGNATURE-
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On 7 November 2013 04:15, Ian Stakenvicius a...@gentoo.org wrote: The bug that was filed, is that a user didn't do a full emerge -uDN @world prior to emerging (upgrading?) firefox, and they had icu-49 already installed. Because the firefox dep didn't have a minimum version, portage didn't see upgrading icu as a requirement before firefox emerged. Theres another scenario not listed here which can still happen: The end user has a copy of icu-49.ebuild somewhere in their portage layout still. Either this is due to a published overlay containing it, or them locally maintaining their own private overlay. The update world thing *may* still work in such a circumstance, but you'd have to change the policy to say Update to a something that is in ::gentoo before merging packages from ::gentoo, which is getting a bit logically messy. Even then, it may not be apparent that there is a problem, for instance, if they have the overlay in place, *AND* they've locally masked newer versions of icu, for some reason ( perhaps they have 3rd party software they're locally maintaining that requires an older version of icu ). Here, the *only* sane approach is for firefox to declare it needs a certain version of icu as a minimum, regardless of what is, and what isn't visible in tree, so that the end user at very least gets told firefox needs this, and its then their responsibility to sort out the problem if they've caused one. -- Kent
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/11/13 10:26 AM, Kent Fredric wrote: On 7 November 2013 04:15, Ian Stakenvicius a...@gentoo.org mailto:a...@gentoo.org wrote: The bug that was filed, is that a user didn't do a full emerge -uDN @world prior to emerging (upgrading?) firefox, and they had icu-49 already installed. Because the firefox dep didn't have a minimum version, portage didn't see upgrading icu as a requirement before firefox emerged. Theres another scenario not listed here which can still happen: The end user has a copy of icu-49.ebuild somewhere in their portage layout still. Either this is due to a published overlay containing it, or them locally maintaining their own private overlay. Yes, however there's no way to keep overlays (especially unofficial ones) from messing with what portage does, and IMO there shouldn't be - -- I think we've made it clear that conflicts arising between in-tree and overlay packages (whether they be deps or not) are for the end-users to resolve. That said, I agree: Here, the *only* sane approach is for firefox to declare it needs a certain version of icu as a minimum, regardless of what is, and what isn't visible in tree, so that the end user at very least gets told firefox needs this, and its then their responsibility to sort out the problem if they've caused one. Option #2 to me also seems to be the way to go.. If we can reach a consensus here, adding some text to the devmanual or developer guide should suffice, yes? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlJ6YykACgkQ2ugaI38ACPApYgD/fx1QrWxlBWOxJX5lsIqS1DVp E3ClB9ketAWsPt7LmqMBAI1mVm/td9BLyfSGSP+Qi43kTzR+TISwecvPmqnvsKYE =W3Ul -END PGP SIGNATURE-
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On Wed, 2013-11-06 at 10:15 -0500, Ian Stakenvicius wrote: However, it's been a long-standing general practise that if there are no deps in the tree older than what is necessary for a package, that package doesn't need to have a minimum version on the dependency atom. As such, issues similar to this are probably lying in wait all other the place in the tree. this is a common misconception: ebuilds must have min. deps matching their requirements (exactly because of this problem) it can be fixed on the user side by 'emerge -uDN world' meanwhile but this doesn't mean the ebuild doesn't have a bug, even if minor Alexis.
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On 11/6/13 7:15 AM, Ian Stakenvicius wrote: The synopsis of the situation is that the latest firefox ebuild now depends on icu, specifically icu-50.1 or above. When this version of firefox was added to the tree, the lowest version of icu in the tree was icu-51.0 -- in fact, icu-48 through icu-50 were dropped from the tree about 2 months prior to the new firefox being added. The bug that was filed, is that a user didn't do a full emerge -uDN @world prior to emerging (upgrading?) firefox, and they had icu-49 already installed. Because the firefox dep didn't have a minimum version, portage didn't see upgrading icu as a requirement before firefox emerged. I've seen things like that happening. I wouldn't really create yet another policy (it doesn't make things happen). I'd leave it up to the maintainer: it'd be fine to declare it not a bug, and it'd also be fine to fix. I'm generally leaning toward fixing and adding the minimum version to deps. Helps the users, and doesn't really hurt maintainability. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [warning] the bug queue has 89 bugs
On Wed, 6 Nov 2013 14:00:02 +0200 (EET) Alex Alexander wi...@gentoo.org wrote: Our bug queue has 89 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Is this notice automated? Feel free to ping us (b-w) as well or instead. Thank you to everyone whom helped along here and there. Spent a full two hours on helping to empty the queue; there are some bugs with pending information left, and one I don't know how to assign. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On 06/11/2013 17:26, Kent Fredric wrote: On 7 November 2013 04:15, Ian Stakenvicius a...@gentoo.org mailto:a...@gentoo.org wrote: The bug that was filed, is that a user didn't do a full emerge -uDN @world prior to emerging (upgrading?) firefox, and they had icu-49 already installed. Because the firefox dep didn't have a minimum version, portage didn't see upgrading icu as a requirement before firefox emerged. Theres another scenario not listed here which can still happen: The end user has a copy of icu-49.ebuild somewhere in their portage layout still. Either this is due to a published overlay containing it, or them locally maintaining their own private overlay. The update world thing *may* still work in such a circumstance, but you'd have to change the policy to say Update to a something that is in ::gentoo before merging packages from ::gentoo, which is getting a bit logically messy. Even then, it may not be apparent that there is a problem, for instance, if they have the overlay in place, *AND* they've locally masked newer versions of icu, for some reason ( perhaps they have 3rd party software they're locally maintaining that requires an older version of icu ). Here, the *only* sane approach is for firefox to declare it needs a certain version of icu as a minimum, regardless of what is, and what isn't visible in tree, so that the end user at very least gets told firefox needs this, and its then their responsibility to sort out the problem if they've caused one. I agree with this sentiment. It's always been my view that the needs of a package are driven by the package itself, not by the tree. Rationale: A package will build and run as long as it's own requirements are met regardless of what the tree states. We have layman overlays and user's own overlays. Whilst these are not 100% supported by Gentoo they are not banned either. They are also not barely tolerated, it's more a case of overlays are not a problem and users are welcome to use them as long as they don't conflict with or break the tree for that user. This needn't be onerous. Presumably ebuild maintainers read the README and Changelog, these often state the versions of deps the package supports. Take that information and put it in the ebuild. Maintainers are under no obligation to provide the absolute minimum version of a dep, only at least one that will work. If the user decides to make other versions available to his system by whatever means, then portage can deal with it by and large transparently. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] [warning] the bug queue has 89 bugs
On Wed, Nov 6, 2013 at 6:08 PM, Tom Wijsman tom...@gentoo.org wrote: On Wed, 6 Nov 2013 14:00:02 +0200 (EET) Alex Alexander wi...@gentoo.org wrote: Our bug queue has 89 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Is this notice automated? Feel free to ping us (b-w) as well or instead. Thank you to everyone whom helped along here and there. Spent a full two hours on helping to empty the queue; there are some bugs with pending information left, and one I don't know how to assign. It's automated, check runs once a day. Good work everyone, queue is down to 9 bugs at the moment :) Cheers, -- Alex Alexander + wired + www.linuxized.com + www.leetworks.com
Re: [gentoo-dev] News item for review: python-exec package move
On Wed, 6 Nov 2013 16:12:47 +0100 Michał Górny mgo...@gentoo.org wrote: Please note that if you applied any kind of package-specific ^ have applied If you applied keywords to dev-python/python-exec in order to unmask ^ have applied Python 3.3 on a stable system, please consider removing the keywords ^ these Other than that it looks perfect; it also seems to take into account the users having problems in the forums [1], for which the original instructions you gave did not appear to work. +1 for the details! :) [1]: http://forums.gentoo.org/viewtopic-t-974412.html -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] News item for review: python-exec package move
On Wed, Nov 6, 2013 at 4:12 PM, Michał Górny mgo...@gentoo.org wrote: Please review the following news item. I would prefer committing it as soon as I get an ACK from all the relevant parties since the issue is hitting users pretty hard. LGTM. I have two questions that should not block this news item from going live: - I tend to upgrade with emerge -uavD --changed-use world, and this didn't solve the blocker for me by itself. I had to emerge -C python-exec, then run the upgrade to get it to work. Yet the news item seems to state that -uD should have been enough. - How come we did not think this news item was necessary before we did the package move? Obviously everything would have been better had this news item gone out with the package move, instead of one week later. Cheers, Dirkjan
Re: [gentoo-dev] News item for review: python-exec package move
Dnia 2013-11-06, o godz. 18:14:57 Dirkjan Ochtman d...@gentoo.org napisał(a): On Wed, Nov 6, 2013 at 4:12 PM, Michał Górny mgo...@gentoo.org wrote: Please review the following news item. I would prefer committing it as soon as I get an ACK from all the relevant parties since the issue is hitting users pretty hard. LGTM. I have two questions that should not block this news item from going live: - I tend to upgrade with emerge -uavD --changed-use world, and this didn't solve the blocker for me by itself. I had to emerge -C python-exec, then run the upgrade to get it to work. Yet the news item seems to state that -uD should have been enough. Well, I have no idea why this happens for some people. Unless you were playing with keywords, it simply should work. - How come we did not think this news item was necessary before we did the package move? Obviously everything would have been better had this news item gone out with the package move, instead of one week later. I think we focused on my little testing that showed that portage can handle blockers with '-uD' and assumed users will be able to understand the blocker message. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] News item for review: python-exec package move
Update 1: - applied comments from TomWij, - changed the wording to reflect that 'emerge @world' may not work, - shortened the wiki URI, - added contact info in case of more issues. Title: python-exec package move Author: Michał Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2013-11-07 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: dev-python/python-exec Due to the recent issues which caused dev-python/python-exec:0 to be removed prematurely [1], we had to perform an urgent package move. Since we could not use the automatic updates support in portage, users will notice two python-exec packages and possibly blockers. Currently, dev-lang/python-exec is the real package that contains python-exec and that will be used in the future. dev-python/python-exec is a virtual package that is kept for compatibility with dependencies in already-installed packages. In the most favorable scenario, the package will be upgraded correctly on your next world update if you use the '--deep' (-D) and '--update' (-u) options. If you don't want to perform a complete world update or if it fails for you, you may as well manually upgrade dev-python/python-exec: emerge -1 dev-python/python-exec This will cause portage to update both python-exec packages and resolve the blockers properly. Please note that if you have applied any kind of package-specific modifications to dev-python/python-exec (such as applying keywords through 'package.accept_keywords'), you will need to copy them to dev-lang/python-exec as well. If you have applied keywords to dev-python/python-exec in order to unmask Python 3.3 on a stable system, please consider removing the keywords and reading our wiki page that explains how to properly unmask USE flags [2]. We apologize for all the inconveniences. If you have any more issues with python-exec, please do not hesitate to contact as at #gentoo-python IRC channel (@freenode) or the gentoo-pyt...@lists.gentoo.org mailing list. [1]:https://bugs.gentoo.org/show_bug.cgi?id=489440 [2]:https://wiki.gentoo.org/wiki/Unmasking_non-stable_Python_implementations -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On Wed, 06 Nov 2013 16:48:54 +0100 Alexis Ballier aball...@gentoo.org wrote: On Wed, 2013-11-06 at 10:15 -0500, Ian Stakenvicius wrote: However, it's been a long-standing general practise that if there are no deps in the tree older than what is necessary for a package, that package doesn't need to have a minimum version on the dependency atom. As such, issues similar to this are probably lying in wait all other the place in the tree. this is a common misconception: ebuilds must have min. deps matching their requirements (exactly because of this problem) it can be fixed on the user side by 'emerge -uDN world' meanwhile but this doesn't mean the ebuild doesn't have a bug, even if minor Alexis. When I started contributing via sunrise, I've been adding the minimal versions of dependencies as declared by upstream but I met with very strict enforcement of the policy to not specify minimal version if all the ones in current tree satisfies. Is it documented somewhere or is it just unwritten consensus? What I see is only Ebuild Policy [1e] which doesn't deal with this. .. [1e] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1 --- Jan Matějka| Gentoo Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B signature.asc Description: PGP signature
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/11/13 12:56 PM, yac wrote: On Wed, 06 Nov 2013 16:48:54 +0100 Alexis Ballier aball...@gentoo.org wrote: On Wed, 2013-11-06 at 10:15 -0500, Ian Stakenvicius wrote: However, it's been a long-standing general practise that if there are no deps in the tree older than what is necessary for a package, that package doesn't need to have a minimum version on the dependency atom. As such, issues similar to this are probably lying in wait all other the place in the tree. this is a common misconception: ebuilds must have min. deps matching their requirements (exactly because of this problem) it can be fixed on the user side by 'emerge -uDN world' meanwhile but this doesn't mean the ebuild doesn't have a bug, even if minor Alexis. When I started contributing via sunrise, I've been adding the minimal versions of dependencies as declared by upstream but I met with very strict enforcement of the policy to not specify minimal version if all the ones in current tree satisfies. Is it documented somewhere or is it just unwritten consensus? What I see is only Ebuild Policy [1e] which doesn't deal with this. .. [1e] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1 I searched as well, and couldn't find anything documented one way or the other, either. I concluded that it's unwritten consensus. That's the main reason I wanted to start this discussion -- to effectively start documenting it and get dev's all on the same page. To be honest I think it should be policy or at least a written-down guideline, that dev's should do this within reason -- if an older-than-minimum version of something has been in the tree within the past year. Gone for more than a year should be safe, I expect. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlJ6hKMACgkQ2ugaI38ACPB8RwD/aYX0JSAeb1xsWVejdf65jPVP QSIYlCp5v/gdYw88kdMA/22f9UHoBep+iwJq5uYeHLmJFMRYRELnihBhNJkzM5rE =3xf4 -END PGP SIGNATURE-
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On Wed, Nov 6, 2013 at 1:04 PM, Ian Stakenvicius a...@gentoo.org wrote: On 06/11/13 12:56 PM, yac wrote: On Wed, 06 Nov 2013 16:48:54 +0100 Alexis Ballier aball...@gentoo.org wrote: On Wed, 2013-11-06 at 10:15 -0500, Ian Stakenvicius wrote: However, it's been a long-standing general practise that if there are no deps in the tree older than what is necessary for a package, that package doesn't need to have a minimum version on the dependency atom. As such, issues similar to this are probably lying in wait all other the place in the tree. this is a common misconception: ebuilds must have min. deps matching their requirements (exactly because of this problem) it can be fixed on the user side by 'emerge -uDN world' meanwhile but this doesn't mean the ebuild doesn't have a bug, even if minor Alexis. When I started contributing via sunrise, I've been adding the minimal versions of dependencies as declared by upstream but I met with very strict enforcement of the policy to not specify minimal version if all the ones in current tree satisfies. Is it documented somewhere or is it just unwritten consensus? What I see is only Ebuild Policy [1e] which doesn't deal with this. .. [1e] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1 I searched as well, and couldn't find anything documented one way or the other, either. I concluded that it's unwritten consensus. That's the main reason I wanted to start this discussion -- to effectively start documenting it and get dev's all on the same page. To be honest I think it should be policy or at least a written-down guideline, that dev's should do this within reason -- if an older-than-minimum version of something has been in the tree within the past year. Gone for more than a year should be safe, I expect. I don't think a time limit is necessary here. If there is an identified incompatibility, we should update DEPEND. Note that I do not expect devs to go out of their way to test for the oldest supported version of a dependency; they just shouldn't close bugs as INVALID of someone else has done the work.
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On Wed, Nov 6, 2013 at 11:15 AM, Alan McKinnon alan.mckin...@gmail.com wrote: I agree with this sentiment. It's always been my view that the needs of a package are driven by the package itself, not by the tree. Rationale: A package will build and run as long as it's own requirements are met regardless of what the tree states. ++, and to all that follows. I wouldn't go hunting down and bugging devs for every atom that doesn't specify a minimum version - this stuff isn't always easy to find. However, if somebody offers a minimum version I'd consider it a valid bug. I think giving the resolver as much information as possible will only tend to reduce issues, especially in a distro like Gentoo where doing things differently is the norm. Rich
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On Wed, 6 Nov 2013 13:22:13 -0500 Mike Gilbert flop...@gentoo.org wrote: On Wed, Nov 6, 2013 at 1:04 PM, Ian Stakenvicius a...@gentoo.org wrote: On 06/11/13 12:56 PM, yac wrote: On Wed, 06 Nov 2013 16:48:54 +0100 Alexis Ballier aball...@gentoo.org wrote: On Wed, 2013-11-06 at 10:15 -0500, Ian Stakenvicius wrote: However, it's been a long-standing general practise that if there are no deps in the tree older than what is necessary for a package, that package doesn't need to have a minimum version on the dependency atom. As such, issues similar to this are probably lying in wait all other the place in the tree. this is a common misconception: ebuilds must have min. deps matching their requirements (exactly because of this problem) it can be fixed on the user side by 'emerge -uDN world' meanwhile but this doesn't mean the ebuild doesn't have a bug, even if minor Alexis. When I started contributing via sunrise, I've been adding the minimal versions of dependencies as declared by upstream but I met with very strict enforcement of the policy to not specify minimal version if all the ones in current tree satisfies. Is it documented somewhere or is it just unwritten consensus? What I see is only Ebuild Policy [1e] which doesn't deal with this. .. [1e] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1 I searched as well, and couldn't find anything documented one way or the other, either. I concluded that it's unwritten consensus. That's the main reason I wanted to start this discussion -- to effectively start documenting it and get dev's all on the same page. To be honest I think it should be policy or at least a written-down guideline, that dev's should do this within reason -- if an older-than-minimum version of something has been in the tree within the past year. Gone for more than a year should be safe, I expect. I don't think a time limit is necessary here. If there is an identified incompatibility, we should update DEPEND. Note that I do not expect devs to go out of their way to test for the oldest supported version of a dependency; they just shouldn't close bugs as INVALID of someone else has done the work. +1 very much. --- Jan Matějka| Gentoo Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B signature.asc Description: PGP signature
Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts
Hi, Michael Orlitzky wrote: You should disable OCSP anyway. In Firefox, it's under, Edit - Preferences - Advanced - Encryption - Validation The OCSP protocol is itself is vulnerable to MITM attacks, which is cute when you consider its purpose. Moreover, it sends the address of every website you visit to a third party, which is the real reason to disable it IMO. This is going OT but I cannot leave this statement uncommented, because from my knowledge this is wrong/you are hiding important information everyone should know about: First, if you tell people they should disable OCSP you should also tell these people the consequences: When you disable OCSP in Firefox, there is *no* other way to know if a certificate was revoked or not. This is because Firefox *never* downloaded any CRLs. Furthermore, they removed the possibility to do that [1,2]. If you don't have the possibility to check a certificate for revocation, the whole trust system cannot work because there is no way to tell someone Yes, it is nice that you trust me (=you trust the CA) and I said you can trust this certificate (=the CA you trust has signed the certificate in question) but now I changed my mind (=the CA has revoked the certificate) so please don't trust this certificate anymore. Please read Would you knowingly trust an irrevocable SSL certificate? [3]. And yes, this is a *real* problem, see [7]. Yes, there is a known MITM attacks against OCSP, see [4]. But this is only possible due to bad default settings: Just change your OCSP setting to *require* a valid answer. In Firefox: Edit - Preferences - Advanced - Certificates - Validation Make sure When an OCSP server connection fails, treat the certificate as invalid is checked (or you can just set security.OCSP.require to TRUE). If you are aware about any other know attacks, please share. Regarding your privacy concerns: No, your OCSP-enabled browser won't share the address (URL) with the OCSP responder. Your browser will use the site's certificate serial number to ask the OCSP responder if the certificate is still valid. Yes, the company who is running the OCSP responder is able to log You [IP, UA...] requested status for certificates with the serial number 0x1, 0x2, 0x3 and because the OCSP responder needs some basic knowledge about the certificates it should provide answers for, the operator may know that the certificate with the serial number 0x1 has the Common Name (CN) www.mysecretsite.invalid and 0x2 was issued for www.mydarksecrets.invalid or 0x3 was for www.facebook.com, but the operator doesn't know the URL you visited. I don't say OCSP is perfect. For example an OCSP check will delay the initial SSL handshake, because your browser has to connect to the OCSP responder when it has received the certificate from the server you are connecting to. Depending on your connection and the OCSP responder, this may take some time [5]. But the CRL system doesn't work anymore (and was never working in Firefox, unless you manually added all the CRL distribution points for your CA and Sub CAs...), because VerSign and other big SSL companies are providing 20 MB CRLs. Imagine you would use your phone to visit a website using some kind of mobile connection and it would have to fetch 50+ MBs in CRLs before the website will open... Google for example decided some time ago to disable CRL checks too. They will download CRLs for you and are planing to release these centralized CRLs with normal updates. See [6]. They are improving OCSP. The next big thing is OCSP stapling [8,9] which is now supported by all major browsers and patches are available for most web servers. OCSP stapling was developed to save the extra round trip to the OCSP responder, but OCSP stapling-enabled websites will also increase your privacy, because you don't longer have to tell the OCSP responder the certificate (CN) you want to check. If you are still really concerned about what OCSP may do to your privacy, may I ask if you are also concerned about DNS servers? If not, what's the difference between an OCSP responder which you ask for a serial number, which can be resolved to a CN and a DNS server which you ask for a ... CN? :) Also, you are trusting a CA to secure your connections, but you don't trust the same CA due to privacy concerns? So please, don't just tell anybody to turn off OCSP. Tell them why you may think they should do that. But also tell them about the new risks they have to deal with so that they are able to decide on their own if they want to disable OCSP or not. PS: As long as you are trusting CAs and don't manage the trust of any certificate you are using on your own I recommend to enable OCSP in all your browsers and to treat any kind of invalid OCSP responses as a hard failure, because I want to know if I can trust the certificate used to secure my communication or not. If you don't trust any CA, we don't have to talk about things like OCSP or CRL and revocation...
Re: [gentoo-dev] News item for review: python-exec package move
El mié, 06-11-2013 a las 18:20 +0100, Michał Górny escribió: Dnia 2013-11-06, o godz. 18:14:57 Dirkjan Ochtman d...@gentoo.org napisał(a): On Wed, Nov 6, 2013 at 4:12 PM, Michał Górny mgo...@gentoo.org wrote: Please review the following news item. I would prefer committing it as soon as I get an ACK from all the relevant parties since the issue is hitting users pretty hard. LGTM. I have two questions that should not block this news item from going live: - I tend to upgrade with emerge -uavD --changed-use world, and this didn't solve the blocker for me by itself. I had to emerge -C python-exec, then run the upgrade to get it to work. Yet the news item seems to state that -uD should have been enough. Well, I have no idea why this happens for some people. Unless you were playing with keywords, it simply should work. - How come we did not think this news item was necessary before we did the package move? Obviously everything would have been better had this news item gone out with the package move, instead of one week later. I think we focused on my little testing that showed that portage can handle blockers with '-uD' and assumed users will be able to understand the blocker message. I have also had strange blockers, maybe due python-3.3 (but I have unmasked it properly I think :/). I only could resolve it by installing: dev-lang/python-exec-0. I don't understand why 0.3.1 isn't enough :(
Re: [gentoo-dev] News item for review: python-exec package move
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/11/13 02:56 PM, Pacho Ramos wrote: El mié, 06-11-2013 a las 18:20 +0100, Michał Górny escribió: Dnia 2013-11-06, o godz. 18:14:57 Dirkjan Ochtman d...@gentoo.org napisał(a): On Wed, Nov 6, 2013 at 4:12 PM, Michał Górny mgo...@gentoo.org wrote: Please review the following news item. I would prefer committing it as soon as I get an ACK from all the relevant parties since the issue is hitting users pretty hard. LGTM. I have two questions that should not block this news item from going live: - I tend to upgrade with emerge -uavD --changed-use world, and this didn't solve the blocker for me by itself. I had to emerge -C python-exec, then run the upgrade to get it to work. Yet the news item seems to state that -uD should have been enough. Well, I have no idea why this happens for some people. Unless you were playing with keywords, it simply should work. - How come we did not think this news item was necessary before we did the package move? Obviously everything would have been better had this news item gone out with the package move, instead of one week later. I think we focused on my little testing that showed that portage can handle blockers with '-uD' and assumed users will be able to understand the blocker message. I have also had strange blockers, maybe due python-3.3 (but I have unmasked it properly I think :/). I only could resolve it by installing: dev-lang/python-exec-0. I don't understand why 0.3.1 isn't enough :( I run mostly mixed-keywords systems, and i noticed that the blocker messages were entirely useless and confusing, but that i just needed to keyword dev-lang/python-exec due to the fact that it was in the deplist of one of my other keyworded packages. After I did that emerge -uDN @world just worked. Note that dev-python/python-exec had already been keyworded for the same reason, and I didn't remove that keyword. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlJ6oAYACgkQ2ugaI38ACPA2SQD/V/u5DJLPjgYblMpmgOQWSUm6 xlJlC+YOyh2MKekWRdsBAJqjMgqeK3UJlkMbcN4G1JTzs883ugMaeq8ZeKES4lmq =QEMm -END PGP SIGNATURE-
Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts
On Wed, Nov 06, 2013 at 08:11:52PM +0100, Thomas D. wrote: Hi, Michael Orlitzky wrote: You should disable OCSP anyway. In Firefox, it's under, Edit - Preferences - Advanced - Encryption - Validation The OCSP protocol is itself is vulnerable to MITM attacks, which is cute when you consider its purpose. Moreover, it sends the address of every website you visit to a third party, which is the real reason to disable it IMO. This is going OT but I cannot leave this statement uncommented, because from my knowledge this is wrong/you are hiding important information everyone should know about: First, if you tell people they should disable OCSP you should also tell these people the consequences: When you disable OCSP in Firefox, there is *no* other way to know if a certificate was revoked or not. This is because Firefox *never* downloaded any CRLs. Furthermore, they removed the possibility to do that [1,2]. If you don't have the possibility to check a certificate for revocation, the whole trust system cannot work because there is no way to tell someone Yes, it is nice that you trust me (=you trust the CA) and I said you can trust this certificate (=the CA you trust has signed the certificate in question) but now I changed my mind (=the CA has revoked the certificate) so please don't trust this certificate anymore. Please read Would you knowingly trust an irrevocable SSL certificate? [3]. And yes, this is a *real* problem, see [7]. Yes, there is a known MITM attacks against OCSP, see [4]. But this is only possible due to bad default settings: Just change your OCSP setting to *require* a valid answer. In Firefox: Edit - Preferences - Advanced - Certificates - Validation Make sure When an OCSP server connection fails, treat the certificate as invalid is checked (or you can just set security.OCSP.require to TRUE). If you are aware about any other know attacks, please share. Regarding your privacy concerns: No, your OCSP-enabled browser won't share the address (URL) with the OCSP responder. Your browser will use the site's certificate serial number to ask the OCSP responder if the certificate is still valid. Yes, the company who is running the OCSP responder is able to log You [IP, UA...] requested status for certificates with the serial number 0x1, 0x2, 0x3 and because the OCSP responder needs some basic knowledge about the certificates it should provide answers for, the operator may know that the certificate with the serial number 0x1 has the Common Name (CN) www.mysecretsite.invalid and 0x2 was issued for www.mydarksecrets.invalid or 0x3 was for www.facebook.com, but the operator doesn't know the URL you visited. I don't say OCSP is perfect. For example an OCSP check will delay the initial SSL handshake, because your browser has to connect to the OCSP responder when it has received the certificate from the server you are connecting to. Depending on your connection and the OCSP responder, this may take some time [5]. But the CRL system doesn't work anymore (and was never working in Firefox, unless you manually added all the CRL distribution points for your CA and Sub CAs...), because VerSign and other big SSL companies are providing 20 MB CRLs. Imagine you would use your phone to visit a website using some kind of mobile connection and it would have to fetch 50+ MBs in CRLs before the website will open... Google for example decided some time ago to disable CRL checks too. They will download CRLs for you and are planing to release these centralized CRLs with normal updates. See [6]. They are improving OCSP. The next big thing is OCSP stapling [8,9] which is now supported by all major browsers and patches are available for most web servers. OCSP stapling was developed to save the extra round trip to the OCSP responder, but OCSP stapling-enabled websites will also increase your privacy, because you don't longer have to tell the OCSP responder the certificate (CN) you want to check. If you are still really concerned about what OCSP may do to your privacy, may I ask if you are also concerned about DNS servers? If not, what's the difference between an OCSP responder which you ask for a serial number, which can be resolved to a CN and a DNS server which you ask for a ... CN? :) Also, you are trusting a CA to secure your connections, but you don't trust the same CA due to privacy concerns? So please, don't just tell anybody to turn off OCSP. Tell them why you may think they should do that. But also tell them about the new risks they have to deal with so that they are able to decide on their own if they want to disable OCSP or not. PS: As long as you are trusting CAs and don't manage the trust of any certificate you are using on your own I recommend to enable OCSP in all your browsers and to treat any kind of invalid OCSP responses as a hard failure, because I want to know if I
[gentoo-dev] Re: Policy-level discussion for minimum versions on dependencies
Rich Freeman posted on Wed, 06 Nov 2013 13:28:13 -0500 as excerpted: I think giving the resolver as much information as possible will only tend to reduce issues, especially in a distro like Gentoo where doing things differently is the norm. ++ to both you and Alan McK's thoughts. Meanwhile, I like that last subsentence. Maybe time for a new Gentoo slogan? Gentoo: Where doing things differently is the norm! Hey, Apple can think different, we can DO different! =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: friendly reminder wrt net virtual in init scripts
Thomas D. posted on Wed, 06 Nov 2013 20:11:52 +0100 as excerpted: Michael Orlitzky wrote: You should disable OCSP anyway. In Firefox, it's under, Edit - Preferences - Advanced - Encryption - Validation The OCSP protocol is itself is vulnerable to MITM attacks, which is cute when you consider its purpose. Moreover, it sends the address of every website you visit to a third party, which is the real reason to disable it IMO. This is going OT but I cannot leave this statement uncommented, because from my knowledge this is wrong/you are hiding important information everyone should know about: Thanks. I was going to reply with something like this, but your reply was far better than mine would have been. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] OCSP Was: friendly reminder wrt net virtual in init scripts
mingdao posted on Wed, 06 Nov 2013 14:13:34 -0600 as excerpted: Thanks for the detailed explanation, Thomas. Now, if any one of us turned off OCSP as Michael suggested, what should one do after turning it back on? Could there now be certificates trusted there which should not be? AFAIK, no... except possibly for any ongoing connections and any possible overrides you did during the off time. New connections will automatically be checked again. Meanwhile, another question for Thomas. Is this certificate stapling the same thing google chrome is now doing for the google site, that enabled it to detect the (I think it was) Iranian and/or Chinese CA tampering, allowing them to say a google cert was valid that was actually their MitM cert, as appeared in the tech-news a few months ago? Or was that something different? I had interpreted (well, I think I read, but either the journalist could have been mixed up too, or maybe I was misinterpreting what I read, either way the effect on my understanding is the same) the certificate stapling referred to at the time as indicating that google configured the certs for their own sites into chrome as shipped itself, effectively hard-coding them, NOT as google handling its own OCSP requests, as OCSP cert stapling does. So now I'm wondering if I interpreted wrong then, or if there's actually two different things being referred to as certificate stapling, here. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Suggestion: support the Dev team with system resources
Hello gentoo-dev@, Starting with a little intro, I'm currently providing a Gentoo VM to a gentoo dev (Agostino Sarubbo (ago)) for the purpose of testing/stabilizing/keywording packages, which is part of his task as a developer and being part of the AT team. I've been running the VM for him for a couple of months now and AFAIK he's been giving it a great use ;-). The main idea here is to allow Gentoo contributors and members (not necessary) of the Gentoo community, to be able to support the developer team providing their spare system resources, by, for example, running a Virtual Machine (or any sort of xen, kvm, virtualbox, vmware, whatever...) instance where the devs can run tasks they'd normally wouldn't be able to run with their systems, because: * They're doing some other tests at the moment * They're on ~arch and need stable * They're not on the architecture needed for that testing * Their system is not 'powerful' enough * etc... The purpose of doing this is that the developers that have the time and dedication would be able to run a couple of different tests concurrently, on different 'instances' provided by the community. That will greatly, IMHO, improve the team's performance and not only in the AT field. The instances provided wouldn't forcefully need to meet any specific minimum requirements (this would be decided once (and if) this gets accepted), but a dual core system with 512MB ram would be somewhat an acceptable instance for the bigger arches (x86 amd64), and maybe lower specs for the other arches[1]. As an example here, I'm giving Ago a VirtualBox VM with 2GB ram and 4 virtual CPUs. Also, for the contributors there shouldn't be any minimum uptime to meet, they'll run the instances the time they use their systems, and if they leave them idle all day/night that would just be better, although they should be able to specify to the team normally the hours their systems would be usable by the devs. There should be a list of users that are able to share their resources and each dev(s) would be given a certain number of instances depending on their needs and such. I know that you might think that doing this will lower the contributor's desktop experience (as VMs tend to be somewhat heavy while compiling). The usage of the AUTOGROUP kernel scheduler and cgroups tends to make the desktop very much usable under high CPU pressure. Please review this, and if you agree that it'd be a good idea come with any suggestions to make it happen as well as with any other thoughts/sys-specs/instances we should be looking for. If you don't think this is a good idea or that it won't profit the Gentoo dev team, please tell me why. Regards, Denis M. (Phr33d0m) PS: This is a re-send as I firstly sent it without subscribing to the ML. So sorry if you receive it 2 times. [1] I apologize if this statement is wrong, it's based of my 0 knowledge on the other arches and the resources they need. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
Am Donnerstag, 7. November 2013, 00:18:19 schrieb Denis M.: Hello gentoo-dev@, Starting with a little intro, I'm currently providing a Gentoo VM to a gentoo dev (Agostino Sarubbo (ago)) for the purpose of testing/stabilizing/keywording packages, which is part of his task as a developer and being part of the AT team. I've been running the VM for him for a couple of months now and AFAIK he's been giving it a great use ;-). The main idea here is to allow Gentoo contributors and members (not necessary) of the Gentoo community, to be able to support the developer team providing their spare system resources, by, for example, running a Virtual Machine (or any sort of xen, kvm, virtualbox, vmware, whatever...) instance where the devs can run tasks they'd normally wouldn't be able to run with their systems, because: ... I appreciate the idea, but security-wise it's pretty dangerous - given that you as a Gentoo dev are doing sensitive work that may affect many people on a machine not controlled by you yourself nor Gentoo Infra. Call me paranoid, but please no. And in absolutely no case one should commit to the tree from such a machine, even with stuff like agent forwarding. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
On 11/07/2013 12:37 AM, Andreas K. Huettel wrote: Am Donnerstag, 7. November 2013, 00:18:19 schrieb Denis M.: Hello gentoo-dev@, Starting with a little intro, I'm currently providing a Gentoo VM to a gentoo dev (Agostino Sarubbo (ago)) for the purpose of testing/stabilizing/keywording packages, which is part of his task as a developer and being part of the AT team. I've been running the VM for him for a couple of months now and AFAIK he's been giving it a great use ;-). The main idea here is to allow Gentoo contributors and members (not necessary) of the Gentoo community, to be able to support the developer team providing their spare system resources, by, for example, running a Virtual Machine (or any sort of xen, kvm, virtualbox, vmware, whatever...) instance where the devs can run tasks they'd normally wouldn't be able to run with their systems, because: ... I appreciate the idea, but security-wise it's pretty dangerous - given that you as a Gentoo dev are doing sensitive work that may affect many people on a machine not controlled by you yourself nor Gentoo Infra. I completely agree with this, but it's not entirely true. Why? I'll give the example of the AT team: 1. You sync the tree before you start your work (that way you verify the tree is clean). 2. Then you start testing the packages or bugs you're after, which in matter of security is meaningless because testing packages is usually just compiling and running to see if it works as expected. 2.1. Apply random patches to fix if there's an issue. 2.2. goto 2. 3. etc... I see no issue in this in matter of security. Another example would be devs testing packages under development (internal usage in gentoo), for example how new versions of openrc/systemd/glibc/whatever can affect X. I do understand your concern, although I wouldn't call you paranoid as it's just normal to not trust a system that's not completely under your control, but as I said, you don't really... 'care' about it/that. Call me paranoid, but please no. And in absolutely no case one should commit to the tree from such a machine, even with stuff like agent forwarding. Of course! Commiting or any other form of direct communication with the gentoo infra. (either commit to tree or `git push`-ing to any of the other gentoo repos) would be highly discouraged, and I didn't, in any moment, think someone would think of doing that :P. The idea behind this is using the provided instance only and exclusively for testing something you'd normally can't do on your system. Regards, Denis M. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts
Hi, mingdao wrote: Now, if any one of us turned off OCSP as Michael suggested, what should one do after turning it back on? Could there now be certificates trusted there which should not be? Well, only your current browser session can be affected. For Firefox: History - Clear Recent History - Details In the dialog, just check Active logins and click Clear Now. This should clear any existing SSL state cache. For Chrome it is a bit harder, because Chrome doesn't offer such an option AFAIK (see [1]). Also, it depends on the SSL backend you are using. PS: To enable OCSP in Chrome, go to chrome://settings/advanced Security Manage Certificates... Check for server certificate revocation It is disabled by default, due to performance concerns :( See also: = [1] http://code.google.com/p/chromium/issues/detail?id=90454 -- Regards, Thomas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/06/2013 02:11 PM, Thomas D. wrote: This is going OT but I cannot leave this statement uncommented, because from my knowledge this is wrong/you are hiding important information everyone should know about: I figure everyone here is smart enough to google OCSP before unchecking the box. This isn't the place to argue that the CA system is broken, but I will respond to a few points. Yes, there is a known MITM attacks against OCSP, see [4]. But this is only possible due to bad default settings: Just change your OCSP setting to *require* a valid answer. In Firefox: ... If you are aware about any other know attacks, please share. Replay attacks, mentioned in the RFC (or Google). These could be mitigated, but no one has bothered. Regarding your privacy concerns: No, your OCSP-enabled browser won't share the address (URL) with the OCSP responder. Your browser will use the site's certificate serial number to ask the OCSP responder if the certificate is still valid. Yes, the company who is running the OCSP responder is able to log You [IP, UA...] requested status for certificates with the serial number 0x1, 0x2, 0x3 and because the OCSP responder needs some basic knowledge about the certificates it should provide answers for, the operator may know that the certificate with the serial number 0x1 has the Common Name (CN) www.mysecretsite.invalid and 0x2 was issued for www.mydarksecrets.invalid or 0x3 was for www.facebook.com, but the operator doesn't know the URL you visited. This is a long way of saying it sends the address of every website you visit to a third party. They are improving OCSP. The next big thing is OCSP stapling [8,9] which is now supported by all major browsers and patches are available for most web servers. OCSP stapling was developed to save the extra round trip to the OCSP responder, but OCSP stapling-enabled websites will also increase your privacy, because you don't longer have to tell the OCSP responder the certificate (CN) you want to check. That's cool, but it doesn't exist now and won't for years. And as a visitor you have no way of knowing whether the server supports it (== your privacy will be kept). If you are still really concerned about what OCSP may do to your privacy, may I ask if you are also concerned about DNS servers? If not, what's the difference between an OCSP responder which you ask for a serial number, which can be resolved to a CN and a DNS server which you ask for a ... CN? :) Only two DNS servers are involved; mine and those of the domain I'm visiting. Also, you are trusting a CA to secure your connections, but you don't trust the same CA due to privacy concerns? You're conflating two things here. I trust AES to keep my connection safe. I don't send my data to the CA. If you don't trust any CA, we don't have to talk about things like OCSP or CRL and revocation... Well there we agree. Why would you trust the CAs? You don't know them personally and you aren't their customer. Do you trust the governments of the USA and China? (Hint: you shouldn't.) If the answer is no, then you don't trust the CA system. So whether or not you trust them to revoke that authentication is a moot point. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJSeuYkAAoJEBxJck0inpOigpUP/3AqhOXf3D5nPzHZumJw9iv6 /9eXu2MMgoZTdwILAc0GnlSwnstTgaI/WZYFHRsU24DQsCQxCMr8VnJnirRNv0Zz EB+fu3i991e85BloxaZaC3nDcJ5cDB3WjEOfUi4adHVEaY71eAKlwge2P9jG2t9B 60HslYxK9pBhmCzqfpxViunSZV36w4mGOSB9X8ajagkklW4BGzP508czzX0KU/HH zBxhRxowuLKzIKQZ0R996bEk7b0STadNbTllSyF4850Iftm9Aj+smYHXmbO5wT1I lYWJGP11bAZfbObstG+ZepST98FxsZGke80LicydNIvZ13tnqYLYERYdxb9GVMB/ /hO4wi53ltvEtb6/7uy/ec3jg5x8V3e6ZidHu/4ObToYZF4gzsNZ8agLazFEHA54 Xpk3+nh8ypJPBdBiJZuuYQckUFwXzTpEXqpfb5X6c38F6pOxNElexuAa57coIqoy M8ZsMoTr3oCYsRC5lRFmb6uv9WZZDi6iRSTh5z78fzxc3/ynF7SYmJIQEIKzZDnn FxEAjjhLrJtFCkfFWd1GaIJjrwLjcX+laMJrx6zqkjG3BvQRGTvO2md5m7WoX0v9 0MmxfMsjkQpDV7e/w4gxNG6aZzf1kvBZXPhdFuLJM1NEbD40xoJC90E+y9LsENbV ++m0ObSQf+JfCMcqH0BS =PbZR -END PGP SIGNATURE-
Re: [gentoo-dev] OCSP Was: friendly reminder wrt net virtual in init scripts
Hi, Duncan wrote: Meanwhile, another question for Thomas. Is this certificate stapling the same thing google chrome is now doing for the google site, that enabled it to detect the (I think it was) Iranian and/or Chinese CA tampering, allowing them to say a google cert was valid that was actually their MitM cert, as appeared in the tech-news a few months ago? Or was that something different? I had interpreted (well, I think I read, but either the journalist could have been mixed up too, or maybe I was misinterpreting what I read, either way the effect on my understanding is the same) the certificate stapling referred to at the time as indicating that google configured the certs for their own sites into chrome as shipped itself, effectively hard-coding them, NOT as google handling its own OCSP requests, as OCSP cert stapling does. So now I'm wondering if I interpreted wrong then, or if there's actually two different things being referred to as certificate stapling, here. No, OCSP Stapling is something else. Guess you are talking about HSTS and SSL pinning [1,2]: In Google Chrome, they hard coded some certificates/certificate meta data [3] which must be present in every certificate used for any Google site. If you connect to a Google site for example and this site will use a certificate from a CA not specified in [3] (depending on the service, they may also verify against a list of known fingerprints like EV SSL is working), connection will be terminated and the browser will send some details to Google so they get noticed. See also: = [1] http://blog.chromium.org/2011/06/new-chromium-security-features-june.html [2] https://www.imperialviolet.org/2011/05/04/pinning.html [3] http://www.googblogs.com/uncategorized/changes-to-our-ssl-certificates/ -- Regards, Thomas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] OCSP was: friendly reminder wrt net virtual in init scripts
On 06/11/13 08:00 PM, Michael Orlitzky wrote: On 11/06/2013 02:11 PM, Thomas D. wrote: This is going OT but I cannot leave this statement uncommented, because from my knowledge this is wrong/you are hiding important information everyone should know about: I figure everyone here is smart enough to google OCSP before unchecking the box. This isn't the place to argue that the CA system is broken, but I will respond to a few points. I figure everyone here is smart enough not to spread knowingly-incorrect propaganda. Yes, there is a known MITM attacks against OCSP, see [4]. But this is only possible due to bad default settings: Just change your OCSP setting to *require* a valid answer. In Firefox: ... If you are aware about any other know attacks, please share. Replay attacks, mentioned in the RFC (or Google). These could be mitigated, but no one has bothered. Regarding your privacy concerns: No, your OCSP-enabled browser won't share the address (URL) with the OCSP responder. Your browser will use the site's certificate serial number to ask the OCSP responder if the certificate is still valid. Yes, the company who is running the OCSP responder is able to log You [IP, UA...] requested status for certificates with the serial number 0x1, 0x2, 0x3 and because the OCSP responder needs some basic knowledge about the certificates it should provide answers for, the operator may know that the certificate with the serial number 0x1 has the Common Name (CN) www.mysecretsite.invalid and 0x2 was issued for www.mydarksecrets.invalid or 0x3 was for www.facebook.com, but the operator doesn't know the URL you visited. This is a long way of saying it sends the address of every website you visit to a third party. Addresses, in the context of web browsing, are commonly understood to mean URLs, which include protocol, name, port, and path. OCSP only sends the name portion. Thus, the statement was a long way of saying you are wrong.. They are improving OCSP. The next big thing is OCSP stapling [8,9] which is now supported by all major browsers and patches are available for most web servers. OCSP stapling was developed to save the extra round trip to the OCSP responder, but OCSP stapling-enabled websites will also increase your privacy, because you don't longer have to tell the OCSP responder the certificate (CN) you want to check. That's cool, but it doesn't exist now and won't for years. And as a visitor you have no way of knowing whether the server supports it (== your privacy will be kept). DH3, and incorrect. Firefox, Apache, and nginx all support OCSP stapling RIGHT NOW. If you are still really concerned about what OCSP may do to your privacy, may I ask if you are also concerned about DNS servers? If not, what's the difference between an OCSP responder which you ask for a serial number, which can be resolved to a CN and a DNS server which you ask for a ... CN? :) Only two DNS servers are involved; mine and those of the domain I'm visiting. Not necessarily. Your name server may in fact not be a recursive name server, but delegate some portion to a recursive name server. Also, you are trusting a CA to secure your connections, but you don't trust the same CA due to privacy concerns? You're conflating two things here. I trust AES to keep my connection safe. I don't send my data to the CA. You're conflating two things here. If you trust the CA, you trust them not to perform a MitM attack. If you don't trust any CA, we don't have to talk about things like OCSP or CRL and revocation... Well there we agree. Why would you trust the CAs? You don't know them personally and you aren't their customer. Do you trust the governments of the USA and China? (Hint: you shouldn't.) If the answer is no, then you don't trust the CA system. So whether or not you trust them to revoke that authentication is a moot point. False dichotomy. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] friendly reminder wrt net virtual in init scripts
Hi, Michael Orlitzky wrote: If you are aware about any other know attacks, please share. Replay attacks, mentioned in the RFC (or Google). These could be mitigated, but no one has bothered. The OCSP response is signed. The signature contains a time stamp. If your clock is right, replay attacks are only possible for the expected lifespan of the response. But because it is expected that an OCSP response is valid for x hours, it is not a real problem. But sadly there are some CA which are serving pre-generated OCSP responses which are valid for 7 days (like their CRLs). 7 days can be very long... :( This is a long way of saying it sends the address of every website you visit to a third party. See Alex's reply. I wanted to make it clear to everyone, that the address isn't the full URL. If you are still really concerned about what OCSP may do to your privacy, may I ask if you are also concerned about DNS servers? If not, what's the difference between an OCSP responder which you ask for a serial number, which can be resolved to a CN and a DNS server which you ask for a ... CN? :) Only two DNS servers are involved; mine and those of the domain I'm visiting. Again, please see Alex's reply. Also, if you are using your *own* DNS server, you are *special*. But most people will use the DNS server from their ISP. And I wasn't talking about *special* people who are able to run everything in their own trusted environment. Also, you are trusting a CA to secure your connections, but you don't trust the same CA due to privacy concerns? You're conflating two things here. I trust AES to keep my connection safe. I don't send my data to the CA. CAs not only issue certificates. They should also make sure that they only issue secure certificates: - Require a secure signing algorithm - Require a secure key size You could use the best algorithm available. But if the certificate's private key is shared with others, others are able to decrypt the captured secure traffic. The CAB forum for example says that no CA is allowed to create the key used for any issued customer certificate. So when you are using a pre-populated list of trusted CAs you are also expecting that these CAs are doing their jobs right. IF you don't do that, you shouldn't use them. If you don't trust any CA, we don't have to talk about things like OCSP or CRL and revocation... Well there we agree. Why would you trust the CAs? You don't know them personally and you aren't their customer. Do you trust the governments of the USA and China? (Hint: you shouldn't.) If the answer is no, then you don't trust the CA system. So whether or not you trust them to revoke that authentication is a moot point. Well, that's another discussion. As said before, we don't have to talk about these things if you don't trust a system called Web of trust :) But because most people live in this (broken) system (this is reality!), do you still think telling them they should disable OCSP, which will actually disable an important feature (again, without OCSP you are unable to check a certificate for revocation in Firefox) and make them vulnerable to a new threat is a good thing? -- Regards, Thomas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] OCSP was: friendly reminder wrt net virtual in init scripts
On Wed, Nov 6, 2013 at 7:36 PM, Alex Xu alex_y...@yahoo.ca wrote: On 06/11/13 08:00 PM, Michael Orlitzky wrote: On 11/06/2013 02:11 PM, Thomas D. wrote: This is going OT but I cannot leave this statement uncommented, because from my knowledge this is wrong/you are hiding important information everyone should know about: I figure everyone here is smart enough to google OCSP before unchecking the box. This isn't the place to argue that the CA system is broken, but I will respond to a few points. I figure everyone here is smart enough not to spread knowingly-incorrect propaganda. Regarding your privacy concerns: No, your OCSP-enabled browser won't share the address (URL) with the OCSP responder. Your browser will use the site's certificate serial number to ask the OCSP responder if the certificate is still valid. Yes, the company who is running the OCSP responder is able to log You [IP, UA...] requested status for certificates with the serial number 0x1, 0x2, 0x3 and because the OCSP responder needs some basic knowledge about the certificates it should provide answers for, the operator may know that the certificate with the serial number 0x1 has the Common Name (CN) www.mysecretsite.invalid and 0x2 was issued for www.mydarksecrets.invalid or 0x3 was for www.facebook.com, but the operator doesn't know the URL you visited. This is a long way of saying it sends the address of every website you visit to a third party. Addresses, in the context of web browsing, are commonly understood to mean URLs, which include protocol, name, port, and path. OCSP only sends the name portion. Thus, the statement was a long way of saying you are wrong.. A bit of additional consideration: Given the above statement and RFC 2560, OCSP sends the certificate serial, not the name. With the availability of Wildcard certificates and the subjectAltName parameter, with many certificates that serial will not let the CA actually know which domain you are visiting.
