[gentoo-dev] [PATCH] eutils.eclass: Document optfeature suggests packages not installed
---
Please consider this clarification of optfeature.
Chris
eclass/eutils.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index fe4339f6b89..f35fa5980d7 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -827,8 +827,8 @@ use_if_iuse() {
# @FUNCTION: optfeature
# @USAGE: [other atoms]
# @DESCRIPTION:
-# Print out a message suggesting an optional package (or packages) which
-# provide the described functionality
+# Print out a message suggesting an optional package (or packages)
+# not currently installed which provides the described functionality.
#
# The following snippet would suggest app-misc/foo for optional foo support,
# app-misc/bar or app-misc/baz[bar] for optional bar support
--
2.13.5
Re: [gentoo-dev] [PATCH 2/2] git-r3.eclass: Explicitly warn about unsecure protocols
On Fri, 25 Aug 2017 15:51:25 +0200 Michał Górny wrote:
> W dniu śro, 23.08.2017 o godzinie 11∶46 +0300, użytkownik Andrew
> Savchenko napisał:
> > On Sat, 19 Aug 2017 10:25:02 +0200 Michał Górny wrote:
> > > Explicitly warn about any URI that uses an unsecure protocol (git, http)
> > > even if it's a fallback URI. This is necessary because an attacker may
> > > block HTTPS connections, effectively forcing the fallback to
> > > the unsecure protocol.
> >
> > [...]
> > > + local r
> > > + for r in "${repos[@]}"; do
> > > + if [[ ${r} == git:* || ${r} == http:* ]]; then
> > > + ewarn "git-r3: ${r%%:*} protocol in unsafe and may be
> > > subject to MITM attacks"
> > > + ewarn "(even if used only as fallback). Please use
> > > https instead."
> > > + ewarn "[URI: ${r}]"
> > > + fi
> > > + done
> > > +
> >
> > Sigh... https also makes MITM attacks possible, especially if SSL
> > or TLS < 1.2 is used or are allowed and protocol version downgrade
> > attack may be performed.
> >
> > Such messages create a false impression of a safety of https.
> > Safety more or less can be gained by verifying GPG signatures and
> > fingerprints of the upstream commits, if upstream supports this. Of
> > course using https is better than using http or git, but better
> > only by a bit.
> >
>
> Yes, we can do a whole long debate about problems with HTTPS. Yes, we
> can do an even longer debate about all those fancy solutions that solve
> all the problems in the world, except they're completely not applicable
> in practice. People will become a lot wiser and/or depressed.
>
> However, I'd rather do what I can practically do to make a real
> difference. And I believe that making things a little safer is better
> than claiming that nothing is safe, so let's just abandon all hope
> and continue using completely unsecured protocols.
I agree that better to have some improvement rather than nothing.
> Nevertheless, I've changed the wording a bit to avoid giving this 'false
> impression' that https is entirely secure.
Thanks, that was my main intent: to have correct docs.
Best regards,
Andrew Savchenko
pgp40FV5ZOm5W.pgp
Description: PGP signature
Re: [gentoo-dev] [PATCH 2/2] git-r3.eclass: Explicitly warn about unsecure protocols
On Fri, 25 Aug 2017 17:46:01 +0200 Hanno Böck wrote: > On Wed, 23 Aug 2017 11:46:02 +0300 > Andrew Savchenko wrote: > > > Sigh... https also makes MITM attacks possible, especially if SSL > > or TLS < 1.2 is used or are allowed and protocol version downgrade > > attack may be performed. > > None of that is true. > > You're probably referring to attacks that were specific to certain > browser weaknesses, but they're irrelevant for this use case. Some attack are indeed implementation specific, but there are several which are design flaws, e.g.: 1) BEAST attack[1]: TLS 1.0 is vulnerable regrardless of implementation (and all SSL versions). 2) BREACH attack[2]: basically this is a side-channel attack for compressed traffic. All TLS versions are still vulnerable, the only practical mitigation is to disable compression. It can be argued if this is a vulnerability in TLS or TLS protocol has nothing to do with side channels, but if a protocol is vulnerable to a side-channel implementation-agnostic attack, it is considered by many as a protocol misdesign. Really SSL/TLS are very good examples of how crypto solutions should not be designed and implemented. [1] https://www.gracefulsecurity.com/what-is-beast/ [2] http://breachattack.com/ Best regards, Andrew Savchenko pgpHlWZBJH1hu.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] sys-boot/grub:0 (GRUB legacy) sunset planning
Hi, On Sat, 2 Sep 2017 15:56:04 + "Robin H. Johnson" wrote: > - Are there other use cases that need grub-static? I have used grub-static to boot Gentoo Systems built with Address Sanitizer. I have to check whether it's feasible to replace that with grub2, but it will probably be complicated. The problem is that you can't build full grub with asan, but you also cannot build the parts that require external libraries (notably ncurses) without asan. If grub-static gets last-rited from main gentoo I'll probably just keep a copy of it in the asantoo overlay. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 pgpYskrxPOZvj.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Document optfeature suggests packages not installed
On 09/03/2017 11:56 AM, Chris Mayo wrote: > # > # The following snippet would suggest app-misc/foo for optional foo support, > # app-misc/bar or app-misc/baz[bar] for optional bar support > Would the @EXAMPLE tag[0] make sense here? [0] https://devmanual.gentoo.org/eclass-writing/index.html
[gentoo-dev] Re: Categories for GUI stuff x11 and wayland
Kent Fredric posted on Sun, 03 Sep 2017 18:44:00 +1200 as excerpted: > On Wed, 30 Aug 2017 14:01:08 -0400 > "William L. Thomson Jr." wrote: > >> Examples >> x11-libs/gtk+ >> x11-terms/terminology > > "desktop" came to mind for me for some reason. > > "desktop-apps/" > "desktop-libs/" > "desktop-terms/" > "desktop-themes/" > > All appeal more to me than > > "gui-apps/" > "gui-libs/" > "gui-terms/" > "gui-themes/" > > "Gui" just seems too vague and generic here, and also feels like > double-dipping. Vague/generic agreed in general. I'm not sure enough what you meant by double-dipping (tho I have a couple ideas) to say I agree there. But... > And it will be additionally confusing if any of those apps don't have > any GUI, like for instance: > > gui-apps/xset > > That just seems backwards to me. > >desktop-apps/xset > > Alright, I guess. > > Maybe a category for non-graphical desktop-related tools should exist > instead. > >desktop-tools/xset How many of these xorg-suite apps have-been/will-be actually ported to wayland? I was under the impression that most of them will not be ported, and it'll be the up to whatever compositor and accompanying toolkit you choose to provide that functionality, as they generally already do... to a point. Certainly the compositor (aka super-window-manager) is the only app allowed to control/delegate many of the functions xset, xrandr, etc, set for xorg in common, for security reasons, because wayland simply doesn't let one app mess with and spy on another app's input stream, for instance, as X does. If only the compositor and/or apps it specifically authenticates for the purpose are allowed to do such settings, it quickly becomes a toolkit/DE function, and generic versions don't make a lot of sense as they simply won't work. In which case, keeping the "legacy" x11-* names for such x-specific apps, the better to eventually deprecate, mask, and send off to the user-maintained "X-sunset" overlay, may make the most sense and will almost certainly be less trouble. And where there is a port, as presumably there is or will be for many of the x11-libs, does it make sense to keep separate x11-* and wayland-* categories where they differ, or throw them all together in a heap? Meanwhile, the objection to "desktop-*" is that it may well look about as relevant in a few years as "mainframe-*" would look today, due to mobile, wearables, and possibly ultimately injectibles. > IDK. > > I'm not committed to anything I've said here, just food for thought. Same here. My biggest concern is simply avoiding, if possible, setting up new categories now, only to have to redo them in 2-5 when hindsight makes them look stupid. It may not be possible, but to the extent it is... Other than that, I've no particular shed color preference, other than don't make it 50 characters long or something so exotic we have to refer to it as "the category formerly known as x11-*." =:^) -- 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] Automated Package Removal and Addition Tracker, for the week ending 2017-09-03 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2017-09-03 23:59 UTC. Removals: dev-lang/gnat-gcc20170830-18:50 pacho 7276e4d8650 virtual/gnat 20170830-18:50 pacho 7276e4d8650 Additions: app-doc/votca-csg-manual 20170903-14:08 junghans ee25acf25bc app-text/coolreader 20170830-16:24 grozin 8a74b3274e7 dev-lua/luacheck 20170825-18:34 mgorny 291aaa6f249 dev-python/deprecation 20170828-21:32 prometheanfire f6223f7603f dev-python/os-traits 20170830-20:54 prometheanfire b40eee97dd3 dev-python/ovsdbapp 20170830-19:13 prometheanfire 2d1f3f7e1fd dev-python/pyperclip 20170828-18:16 prometheanfire 0f61be24d61 dev-python/pypowervm 20170830-21:05 prometheanfire cc2ff570e61 dev-python/python-zunclient 20170830-21:39 prometheanfire bf7ca7eb0af dev-ros/imu_complementary_filter 20170830-09:17 aballier 0aa380e1ad1 dev-ros/imu_filter_madgwick 20170830-09:23 aballier dcc28968055 dev-ros/rviz_imu_plugin 20170830-09:27 aballier c95c902cf7e net-irc/atheme-services 20170623-02:56 mgorny bd0cdb2fe6e ros-meta/imu_tools 20170830-09:29 aballier 1b7c139263b sci-biology/bcftools 20170902-12:33 soap a26495e2ae6 sci-chemistry/votca-ctp 20170903-14:38 junghans 2dab70fd225 sci-libs/votca-moo 20170903-14:38 junghans 0dfe99169e1 sys-apps/crazydiskinfo 20170831-20:29 monsieurp 7636ed80f7c www-client/luakit20170825-18:35 mgorny 80113224e3c -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-lang/gnat-gcc,removed,pacho,20170830-18:50,7276e4d8650 virtual/gnat,removed,pacho,20170830-18:50,7276e4d8650 Added Packages: sci-chemistry/votca-ctp,added,junghans,20170903-14:38,2dab70fd225 sci-libs/votca-moo,added,junghans,20170903-14:38,0dfe99169e1 app-doc/votca-csg-manual,added,junghans,20170903-14:08,ee25acf25bc sci-biology/bcftools,added,soap,20170902-12:33,a26495e2ae6 www-client/luakit,added,mgorny,20170825-18:35,80113224e3c dev-lua/luacheck,added,mgorny,20170825-18:34,291aaa6f249 net-irc/atheme-services,added,mgorny,20170623-02:56,bd0cdb2fe6e ros-meta/imu_tools,added,aballier,20170830-09:29,1b7c139263b dev-ros/rviz_imu_plugin,added,aballier,20170830-09:27,c95c902cf7e dev-ros/imu_filter_madgwick,added,aballier,20170830-09:23,dcc28968055 dev-ros/imu_complementary_filter,added,aballier,20170830-09:17,0aa380e1ad1 sys-apps/crazydiskinfo,added,monsieurp,20170831-20:29,7636ed80f7c dev-python/python-zunclient,added,prometheanfire,20170830-21:39,bf7ca7eb0af dev-python/pypowervm,added,prometheanfire,20170830-21:05,cc2ff570e61 dev-python/os-traits,added,prometheanfire,20170830-20:54,b40eee97dd3 dev-python/ovsdbapp,added,prometheanfire,20170830-19:13,2d1f3f7e1fd app-text/coolreader,added,grozin,20170830-16:24,8a74b3274e7 dev-python/deprecation,added,prometheanfire,20170828-21:32,f6223f7603f dev-python/pyperclip,added,prometheanfire,20170828-18:16,0f61be24d61 Done.
[gentoo-dev] Heads-up on PATH changes in baselayout-2.4
If you haven't noticed, there was a change in baselayout-2.4 that moved the default PATH setting from /etc/profile into /etc/env.d/50baselayout. This change allows other packages to prepend or append their PATH settings by installing files before or after sequence 50 in /etc/env.d. See bug 255695. This has the immediate effect of moving the toolchain-related PATH settings (00glibc, 04gcc, 05binutils) to the left of the "default" system PATH. This wasn't necessarily intentional, but it should make for a minor performance improvement since gcc-wrapper is bypassed. I haven't noticed any problems. More generally, this change occurred a couple of months ago, and there doesn't appear to have been any major fallout in ~arch. However, bug 629846 was opened today, which made the suggestion that we make a more public call for testing. So, if you maintain a package that installs a PATH setting in /etc/env.d, please check it to ensure that it is not causing conflicts with binaries that live in the default PATH. If needed, consider moving them to the right by choosing a number higher than 50.
Re: [gentoo-dev] Re: Categories for GUI stuff x11 and wayland
On Sun, 3 Sep 2017 23:37:34 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Vague/generic agreed in general. I'm not sure enough what you meant > by double-dipping (tho I have a couple ideas) to say I agree there. Yeah. To an extent these days its just "app" practically *implies* a GUI. It doesn't, strictly, speaking, but its just such a generic term I have a hard time imagining somebody using it as a classifier. > How many of these xorg-suite apps have-been/will-be actually ported to > wayland? I was under the impression that most of them will not be > ported, and it'll be the up to whatever compositor and accompanying > toolkit you choose to provide that functionality, as they generally > already do... to a point. Certainly the compositor (aka > super-window-manager) is the only app allowed to control/delegate many > of the functions xset, xrandr, etc, set for xorg in common, for > security reasons, because wayland simply doesn't let one app mess with > and spy on another app's input stream, for instance, as X does. If > only the compositor and/or apps it specifically authenticates for the > purpose are allowed to do such settings, it quickly becomes a > toolkit/DE function, and generic versions don't make a lot of sense > as they simply won't work. Well, in this case it was more an example of "a tool that has some desktop mechanics, but does not in fact have any Graphical User Interface". "xset" augments *the environment itself* And I simply reasoned that, this, being Unix, we'd likely have equivalent, GUI-less applications that perform various display related services, like xbacklight, or transset, or xrandr. I'm not saying those binaries would literally be ported, only that their utility is such that I'd expect to see equivalents/analogues emerge for wayland. ( intel-gpu-tools for example have neither GUI, or really X specific behaviour aside from its gpu-overlay ) > > In which case, keeping the "legacy" x11-* names for such x-specific > apps, the better to eventually deprecate, mask, and send off to the > user-maintained "X-sunset" overlay, may make the most sense and will > almost certainly be less trouble. > > And where there is a port, as presumably there is or will be for > many of the x11-libs, does it make sense to keep separate x11-* > and wayland-* categories where they differ, or throw them all together > in a heap? Right, there's going to be plenty of examples of things that aren't portable, and will need to stay in perpetuity in x11-* . x11-drivers are probably a good example. Though I'm in no hurry to deprecate X11, wayland will take even longer than systemd for me to go "Ok, yes, now we should switch everyone to this" > Meanwhile, the objection to "desktop-*" is that it may well look about > as relevant in a few years as "mainframe-*" would look today, due to > mobile, wearables, and possibly ultimately injectibles. > > > IDK. > > > > I'm not committed to anything I've said here, just food for > > thought. > > Same here. My biggest concern is simply avoiding, if possible, > setting up new categories now, only to have to redo them in 2-5 when > hindsight makes them look stupid. It may not be possible, but to the > extent it is... Other than that, I've no particular shed color > preference, other than don't make it 50 characters long or something > so exotic we have to refer to it as "the category formerly known as > x11-*." =:^) > Yeah. At this point there's not much value in a switch. And I'm not entirely happy with either "gui-" or "desktop-". "x11-" is, for all its warts, more useful than either of those still. I'm tempted to suggest something like "ux-", which conceptually encompasses GUI/UI/Display concerns, and having an "x" gives a nod to its legacy as being "x" without it being part of the definition :) Its also nice to keep the sort ordering reasonably close: sys-* virtual www-* x11-* xfce-* Becomes sys-* ux-* virtual www-* xfce-* Which should help anyone confused why the category they're looking for isn't in /usr/portage any more when they throw an `ls` down there. pgphnMgsEgXUg.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Categories for GUI stuff x11 and wayland
On Mon, Sep 4, 2017 at 12:48 AM, Kent Fredric wrote: > I'm tempted to suggest something like "ux-", which conceptually > encompasses GUI/UI/Display concerns, and having an "x" gives a nod to > its legacy as being "x" without it being part of the definition :) > UX is overly broad, as I could, for example, design a CLI user experience. Nothing says I need to use images or a mouse. There is also the unrelated concern of mine that UX is a fake term that people made up so that they could charge consulting fees to people who don't know any better. Inasmuch as my membership to this list makes my opinion valid, I think "desktop-*" is a very good solution. A desktop is a paradigm that some would say is intrinsically linked to a graphical user interface. People who use tiling or other experimental window managers might see a desktop as something a graphical input system can implement, in which case "gui-*" could be the most technically generic term. I see no problem with putting programs like `xset` into "gui-tools/*". There may not be any reason to change, as the distinctions in place seem to already be quite arbitrary. Having nested package namespaces might make things better because then you are forced to define the logical relationships between namespaces in a way that is not open to as much interpretation. Respectfully, R0b0t1
