Re: [gentoo-dev] Re: Current Gentoo Git setup / man-in-the-middle attacks
On 30/03/15 10:57, Andrew Savchenko wrote: And using https for that will create a tremendous stress on mirror's CPUs, so this is a bad approach. Not to mention that https itself is very hapless protocol with tons of vulnerabilities (all SSL versions are affected and most TLS implementations). This is spreading FUD. -- Thomas Kahle http://dev.gentoo.org/~tomka/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Current Gentoo Git setup / man-in-the-middle attacks
Thomas Kahle schrieb: On 30/03/15 10:57, Andrew Savchenko wrote: And using https for that will create a tremendous stress on mirror's CPUs, so this is a bad approach. Not to mention that https itself is very hapless protocol with tons of vulnerabilities (all SSL versions are affected and most TLS implementations). This is spreading FUD. As far as I know this is correct. All SSL protocol versions including v3 have known vulnerabilities. In addition, a number implementations of TLS 1.0 and 1.1 have been found susceptible to the Poodle and/or FREAK attacks. That the https protocol is hapless is maybe a pessimistic view on the situation. But if all were fine, why some organizations think they need certificate pinning again? Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: Current Gentoo Git setup / man-in-the-middle attacks
On Wed, 01 Apr 2015 14:59:01 +0200 Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: As far as I know this is correct. All SSL protocol versions including v3 have known vulnerabilities. Yeah, but this is a pointless statement in the discussion. Nobody says we should deploy https via sslv3. Of course if people want https they mean https as in 2015 https, not https as in 199x https. In addition, a number implementations of TLS 1.0 and 1.1 have been found susceptible to the Poodle and/or FREAK attacks. Implementation bugs that can be fixed (and are fixed). FREAK is only an issue if you have crazy configured servers (again, https as in 199x), POODLE TLS is only affecting some crappy proprietary load balancers (and erlang, but nobody has proposed to use an erlang https server). People want to deploy pgp sigs (which is - to be clear - a good idea I fully support). I personally found countless minor security issues in gpg lately. Should that stop us from using pgp sigs? of course not. And the claims about https being a performance / cpu stress horror is also completely exaggerated. https performance is mostly a non-issue and based on urban legends rather than benchmarks. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42
[gentoo-portage-dev] [PATCH v3] dispatch-conf: fix unicode handling (bug 545270)
This avoids UnicodeDecodeError problems by using UTF-8 encoding
regardless of the locale.
X-Gentoo-Bug: 545270
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=545270
---
[PATCH v3] adds related fixes in bin/dispatch-conf
bin/dispatch-conf| 9 +
pym/portage/dispatch_conf.py | 4 +---
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/bin/dispatch-conf b/bin/dispatch-conf
index b679910..678a66d 100755
--- a/bin/dispatch-conf
+++ b/bin/dispatch-conf
@@ -11,12 +11,11 @@
# dialog menus
#
-from __future__ import print_function
+from __future__ import print_function, unicode_literals
import atexit
import io
import re
-import shutil
import sys
from stat import ST_GID, ST_MODE, ST_UID
@@ -27,7 +26,7 @@ if
osp.isfile(osp.join(osp.dirname(osp.dirname(osp.realpath(__file__))), .porta
sys.path.insert(0,
osp.join(osp.dirname(osp.dirname(osp.realpath(__file__))), pym))
import portage
portage._internal_caller = True
-from portage import os
+from portage import os, shutil
from portage import _encodings, _unicode_decode
from portage.dispatch_conf import diffstatusoutput, diff_mixed_wrapper
from portage.process import find_binary, spawn
@@ -403,7 +402,9 @@ class dispatch:
newconfigs.sort ()
for nconf in newconfigs:
-nconf = nconf.rstrip ()
+# Use strict mode here, because we want to know if it fails,
+# and portage only merges files with valid UTF-8 encoding.
+nconf = _unicode_decode(nconf, errors='strict').rstrip()
conf = re.sub (r'\._cfg\d+_', '', nconf)
dirname = os.path.dirname(nconf)
conf_map = {
diff --git a/pym/portage/dispatch_conf.py b/pym/portage/dispatch_conf.py
index 790eacb..98939fd 100644
--- a/pym/portage/dispatch_conf.py
+++ b/pym/portage/dispatch_conf.py
@@ -10,15 +10,13 @@ from __future__ import print_function, unicode_literals
import io
import functools
-import os
-import shutil
import stat
import subprocess
import sys
import tempfile
import portage
-from portage import _encodings
+from portage import _encodings, os, shutil
from portage.env.loaders import KeyValuePairFileLoader
from portage.localization import _
from portage.util import shlex_split, varexpand
--
2.3.1
[gentoo-dev] pkgcore reborn
Hey all, pkgcore-0.9 is now in the tree with working EAPI 5 support with the exception of subslot rebuilds. Alongside that, pkgcore-checks (pcheck) has been renamed to pkgcheck and dev-util/pkgcheck-0.5 now in the tree should be able to perform full tree scans or whatever you were doing with pkgcore-checks a long time ago. Also, EAPI 6 support for pkgcore is nearly done so we shouldn't have any lag issues this time compared to EAPI 5. I'm sure there are plenty of bugs to be found so please file issues for the respective project under the pkgcore org on github [1] if you want us to take a look or submit a pull request if you feel like doing a bit of hacking. In terms of future major development, I'll probably be focusing on rewriting the resolver and developing various tools leveraging pkgcore's API. Also of importance is reviving and refreshing the documentation as well as providing more examples and code for using the API. A few readthedocs sites already exist (e.g. [2]) but we haven't updated the process, theme, etc yet so docs are still broken in a few places. If you want to get involved with development, have ideas for features you want implemented, or just want to chat about pkgcore feel free to drop us a line in #pkgcore on freenode. Otherwise the pkgcore-...@googlegroups.com mailing list [3] could be revived as well. Thanks, Tim [1]: https://github.com/pkgcore [2]: http://pkgcore.readthedocs.org [3]: https://groups.google.com/forum/#!forum/pkgcore-dev signature.asc Description: PGP signature
Re: [gentoo-dev] CGA Web™ graphics standards
On 4/1/2015 2:29 PM, Joshua Kinard wrote: Arguably the best 04/01 gag I've seen today. Can we keep this? It'll make browsing the site on old SGI machines so much easier... I thought PetBox was pretty funny too. http://www.redbox.com/petbox?icamp=hp:mss:aprilfoolspetbox:4:1:2015 Brian
[gentoo-dev] CGA Web™ graphics standards
Arguably the best 04/01 gag I've seen today. Can we keep this? It'll make browsing the site on old SGI machines so much easier... -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] CGA Web™ graphics standards
On Wed, 01 Apr 2015 14:29:53 -0400 Joshua Kinard ku...@gentoo.org wrote: Arguably the best 04/01 gag I've seen today. Can we keep this? It'll make browsing the site on old SGI machines so much easier... Nearly as funny as the one about Gentoo switching to CVS. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-portage-dev] [PATCH] binarytree.move_ent: fix binpkg-multi-instance _pkg_paths corruption (bug 545252)
When binpkg-multi-instance support was added in commit 328dd4712f88cbb8ef390ae9eb471afa1ef781d7, the code that adjusts self._pkg_paths in binarytree.move_ent was not fixed to account for the extra directory in the path. Fixes: 328dd4712f88 (binpkg-multi-instance 3 of 7) X-Gentoo-Bug: 545252 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=545252 --- pym/portage/dbapi/bintree.py | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/pym/portage/dbapi/bintree.py b/pym/portage/dbapi/bintree.py index 2f0bc47..b37f388 100644 --- a/pym/portage/dbapi/bintree.py +++ b/pym/portage/dbapi/bintree.py @@ -462,8 +462,7 @@ class binarytree(object): mynewcpv = _pkg_str(mynewcpv, metadata=metadata) new_path = self.getname(mynewcpv) self._pkg_paths[ - self.dbapi._instance_key(mynewcpv)] = os.path.join( - *new_path.split(os.path.sep)[-2:]) + self.dbapi._instance_key(mynewcpv)] = new_path[len(self.pkgdir)+1:] if new_path != mytbz2: self._ensure_dir(os.path.dirname(new_path)) _movefile(tbz2path, new_path, mysettings=self.settings) -- 2.3.1
Re: [gentoo-portage-dev] [PATCH] binarytree.move_ent: fix binpkg-multi-instance _pkg_paths corruption (bug 545252)
On Wed, 1 Apr 2015 11:40:35 -0700 Zac Medico zmed...@gentoo.org wrote: When binpkg-multi-instance support was added in commit 328dd4712f88cbb8ef390ae9eb471afa1ef781d7, the code that adjusts self._pkg_paths in binarytree.move_ent was not fixed to account for the extra directory in the path. Fixes: 328dd4712f88 (binpkg-multi-instance 3 of 7) X-Gentoo-Bug: 545252 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=545252 --- pym/portage/dbapi/bintree.py | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/pym/portage/dbapi/bintree.py b/pym/portage/dbapi/bintree.py index 2f0bc47..b37f388 100644 --- a/pym/portage/dbapi/bintree.py +++ b/pym/portage/dbapi/bintree.py @@ -462,8 +462,7 @@ class binarytree(object): mynewcpv = _pkg_str(mynewcpv, metadata=metadata) new_path = self.getname(mynewcpv) self._pkg_paths[ - self.dbapi._instance_key(mynewcpv)] = os.path.join( - *new_path.split(os.path.sep)[-2:]) + self.dbapi._instance_key(mynewcpv)] = new_path[len(self.pkgdir)+1:] if new_path != mytbz2: self._ensure_dir(os.path.dirname(new_path)) _movefile(tbz2path, new_path, mysettings=self.settings) merge it please :) -- Brian Dolbec dolsen
Re: [gentoo-portage-dev] custom profiles?
On Wed, 2015-04-01 at 14:28 -0700, Zac Medico wrote: On 04/01/2015 02:00 PM, Joakim Tjernlund wrote: On Mon, 2015-03-16 at 11:12 -0700, Zac Medico wrote: On 03/16/2015 09:31 AM, Joakim Tjernlund wrote: On Sun, 2015-03-15 at 16:37 +, Joakim Tjernlund wrote: On Sat, 2015-03-14 at 14:02 -0700, Zac Medico wrote: You can set default USE flags in the profile, and then the users can override those settings locally (both positively and negatively). You should not be using use.mask at all here. The profile can set USE=- flag in make.defaults, or in packages.use, and the user can override that without having to mess with use.mask. That is how I started, I added -thin etc. to profile's package.use and it didn't work so I moved over to package.mask. Now when I try with -thin again in profile's package.use it actually works! I have no idea what got wrong the first time. Anyhow, thank you for your patience. I will continue moving over all Transmode stuff to our new profile the next few days :) hmm, spoke too fast. Negative USE flags in profiles package.use works on other computers but mine :-( I have in profiles package.use: app-emulation/qemu usb usbredir vde qemu_user_targets_x86_64 xattr virtfs static-user -alsa - pulseaudio - bluetooth -opengl but on my computer the -USE flags(-alsa -pulseaudio -bluetooth -opengl) have no effect. I have been looking high and low what could case this but no luck, any pointers ? Maybe you have overridden the default USE_ORDER setting? You can use this command to check it: portageq envvar USE_ORDER That was not it, however: It seems like USE in /etc/portage/make.conf overrides any negative USE flags in profiles/package.use ? Yes, this is a direct result of the default USE_ORDER=env:pkg:conf:defaults:pkginternal:repo:env.d setting. Since conf comes before defaults, make.conf overrides make.defaults. This allows local user settings to override profile settings, which should be intuitive for most people (I think). For make.conf vs make.defaults yes but I am talking about package.use I figured any USE setting in package.use for a specific pkg would override any general USE setting in make.conf or make.defaults. For package.use in /etc/portage this is true but not for package.use located in the profile. Example /etc/portage/make.conf: USE=alsa .../profiles/package.use: app-emulation/qemu -alsa Here USE=alsa overides app-emulation/qemu -alsa ? Seems asymmetric that you can only add but not subtract USE flags in profiles/package.use. You can also subtract them, but it only works for settings that occurred earlier in the profile's make.defaults, in IUSE defaults, or in env.d (a direct result of the default USE_ORDER setting). No, I can not subtract USE flags in profile/package.use if the same flag is present in make.conf Jocke
Re: [gentoo-dev] CGA Web™ graphics standards
On Wed, 01 Apr 2015 14:29:53 -0400 Joshua Kinard wrote: Arguably the best 04/01 gag I've seen today. Can we keep this? Seconded. I'm receiving numerous reports from users that they like this theme very much, it suits Gentoo great. So having it at least somewhere at the web attic will be nice. It'll make browsing the site on old SGI machines so much easier... Best regards, Andrew Savchenko pgp_xYGDvVx0Q.pgp Description: PGP signature
Re: [gentoo-portage-dev] custom profiles?
On 04/01/2015 02:00 PM, Joakim Tjernlund wrote: On Mon, 2015-03-16 at 11:12 -0700, Zac Medico wrote: On 03/16/2015 09:31 AM, Joakim Tjernlund wrote: On Sun, 2015-03-15 at 16:37 +, Joakim Tjernlund wrote: On Sat, 2015-03-14 at 14:02 -0700, Zac Medico wrote: You can set default USE flags in the profile, and then the users can override those settings locally (both positively and negatively). You should not be using use.mask at all here. The profile can set USE=- flag in make.defaults, or in packages.use, and the user can override that without having to mess with use.mask. That is how I started, I added -thin etc. to profile's package.use and it didn't work so I moved over to package.mask. Now when I try with -thin again in profile's package.use it actually works! I have no idea what got wrong the first time. Anyhow, thank you for your patience. I will continue moving over all Transmode stuff to our new profile the next few days :) hmm, spoke too fast. Negative USE flags in profiles package.use works on other computers but mine :-( I have in profiles package.use: app-emulation/qemu usb usbredir vde qemu_user_targets_x86_64 xattr virtfs static-user -alsa -pulseaudio - bluetooth -opengl but on my computer the -USE flags(-alsa -pulseaudio -bluetooth -opengl) have no effect. I have been looking high and low what could case this but no luck, any pointers ? Maybe you have overridden the default USE_ORDER setting? You can use this command to check it: portageq envvar USE_ORDER That was not it, however: It seems like USE in /etc/portage/make.conf overrides any negative USE flags in profiles/package.use ? Yes, this is a direct result of the default USE_ORDER=env:pkg:conf:defaults:pkginternal:repo:env.d setting. Since conf comes before defaults, make.conf overrides make.defaults. This allows local user settings to override profile settings, which should be intuitive for most people (I think). Example /etc/portage/make.conf: USE=alsa .../profiles/package.use: app-emulation/qemu -alsa Here USE=alsa overides app-emulation/qemu -alsa ? Seems asymmetric that you can only add but not subtract USE flags in profiles/package.use. You can also subtract them, but it only works for settings that occurred earlier in the profile's make.defaults, in IUSE defaults, or in env.d (a direct result of the default USE_ORDER setting). -- Thanks, Zac
Re: [gentoo-portage-dev] custom profiles?
On Mon, 2015-03-16 at 11:12 -0700, Zac Medico wrote: On 03/16/2015 09:31 AM, Joakim Tjernlund wrote: On Sun, 2015-03-15 at 16:37 +, Joakim Tjernlund wrote: On Sat, 2015-03-14 at 14:02 -0700, Zac Medico wrote: You can set default USE flags in the profile, and then the users can override those settings locally (both positively and negatively). You should not be using use.mask at all here. The profile can set USE=- flag in make.defaults, or in packages.use, and the user can override that without having to mess with use.mask. That is how I started, I added -thin etc. to profile's package.use and it didn't work so I moved over to package.mask. Now when I try with -thin again in profile's package.use it actually works! I have no idea what got wrong the first time. Anyhow, thank you for your patience. I will continue moving over all Transmode stuff to our new profile the next few days :) hmm, spoke too fast. Negative USE flags in profiles package.use works on other computers but mine :-( I have in profiles package.use: app-emulation/qemu usb usbredir vde qemu_user_targets_x86_64 xattr virtfs static-user -alsa -pulseaudio - bluetooth -opengl but on my computer the -USE flags(-alsa -pulseaudio -bluetooth -opengl) have no effect. I have been looking high and low what could case this but no luck, any pointers ? Maybe you have overridden the default USE_ORDER setting? You can use this command to check it: portageq envvar USE_ORDER That was not it, however: It seems like USE in /etc/portage/make.conf overrides any negative USE flags in profiles/package.use ? Example /etc/portage/make.conf: USE=alsa .../profiles/package.use: app-emulation/qemu -alsa Here USE=alsa overides app-emulation/qemu -alsa ? Seems asymmetric that you can only add but not subtract USE flags in profiles/package.use. Jocke
[gentoo-dev] [warning] the bug queue has 97 bugs
Our bug queue has 97 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 Thanks!
Re: [gentoo-dev] CGA Web™ graphics standards
I thought PetBox was pretty funny too. http://www.redbox.com/petbox?icamp=hp:mss:aprilfoolspetbox:4:1:2015 403 :( -- Best regards, mva signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] CGA Web™ graphics standards
Nearly as funny as the one about Gentoo switching to CVS. From what? AFAIR, it still on CVS... -- Best regards, mva signature.asc Description: This is a digitally signed message part.
[gentoo-portage-dev] [PATCH] dispatch_conf: use portage.os unicode wrapper (bug 545270)
This avoids UnicodeDecodeError problems by using UTF-8 encoding regardless of the locale. X-Gentoo-Bug: 545270 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=545270 --- pym/portage/dispatch_conf.py | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/pym/portage/dispatch_conf.py b/pym/portage/dispatch_conf.py index 790eacb..df02bf2 100644 --- a/pym/portage/dispatch_conf.py +++ b/pym/portage/dispatch_conf.py @@ -10,7 +10,6 @@ from __future__ import print_function, unicode_literals import io import functools -import os import shutil import stat import subprocess @@ -18,7 +17,7 @@ import sys import tempfile import portage -from portage import _encodings +from portage import _encodings, os from portage.env.loaders import KeyValuePairFileLoader from portage.localization import _ from portage.util import shlex_split, varexpand -- 2.3.1
[gentoo-portage-dev] [PATCH v2] dispatch_conf: use portage.os, shutil unicode wrappers (bug 545270)
This avoids UnicodeDecodeError problems by using UTF-8 encoding regardless of the locale. X-Gentoo-Bug: 545270 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=545270 --- [PATCH v2] adds portage.shutil to the imports pym/portage/dispatch_conf.py | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/pym/portage/dispatch_conf.py b/pym/portage/dispatch_conf.py index 790eacb..98939fd 100644 --- a/pym/portage/dispatch_conf.py +++ b/pym/portage/dispatch_conf.py @@ -10,15 +10,13 @@ from __future__ import print_function, unicode_literals import io import functools -import os -import shutil import stat import subprocess import sys import tempfile import portage -from portage import _encodings +from portage import _encodings, os, shutil from portage.env.loaders import KeyValuePairFileLoader from portage.localization import _ from portage.util import shlex_split, varexpand -- 2.3.1
