Re: [gentoo-user] NeoMutt and GnuPG

[Lucas Ramage]

Oh excellent! I will drop those in my dotfiles.

I am going to try and write some of this down in the Gentoo Wiki since
there isn't really that much on the existing page.

https://wiki.gentoo.org/wiki/Mutt

There isn't even a page for NeoMutt.

[gentoo-user] Re: Connman refuses to work

[Melleus]

Alan McKinnon  writes:

> On 07/01/2018 17:45, Melleus wrote:
>> Melleus  writes:
>> 
>>> Neil Bothwick  writes:
>>>
 On Sat, 06 Jan 2018 18:46:25 +0200, Melleus wrote:

>> What do the logs say?  
> That's all I could find in syslog:
>
> connmand[6709]: Aborting (signal 11) [/usr/sbin/connmand]
>
>> Can you start it manually?  
>
> No, it pretends to start but fails silently.

 Looking at the man page, try adding --debug=DEBUG and --nodaemon
>>>
>>> Thank you for helping me.
>>>
>>> --debug=DEBUG is almost silent, but just --debug is more verbose.
>>>
>>> All I see is that something wrong is happening here:
>>>
>>> connmand[2434]: src/iptables.c:__connman_iptables_append() -t mangle -A 
>>> connman-INPUT -j CONNMARK --restore-mark
>>> connmand[2434]: Aborting (signal 11) [connmand]
>> 
>> Thanks again for pointing me to logs. Those iptables was a
>> problem. There are the closed bug #573174. Iptables higher than 1.6
>> breaks connman. The solution is to use iptables lower than 1.6 or
>> connman higher than 1.32. So the combination of connman v1.29 and
>> iptables v1.6.1-r2 just cannot work. But unfortunately for me they both
>> have stable keyword. I beleive that this is a some kind of bug.
>> After I masked iptables higher than 1.6, reemerged the packages and
>> reboot, everything works like it should.
>> 
>> I don't know whether developers are reading this thread, but it would be
>> very nice to keyword only v1.4.21-r1 of iptables with stable keyword
>> (like they have done with kernel recently) or promote to stable some
>> version of connman higher than 1.32 upstream. This would completely
>> have this bug eliminated even before someone other than me hits it.
>
>
> Post your finding to b.g.o.
>
> It's a simple matter to limit which versions of iptables can be used
> with each version of connman. Tracking that, and making changes when
> they become known, is what being a package maintainer is all about.

connman-1.35-r1 arrives to stable. So no need to tinker with iptables
version anymore. The issue dissolved completely.

Re: [gentoo-user] NeoMutt and GnuPG

[Floyd Anderson]

On Wed, 31 Jan 2018 12:18:08 -0500
Lucas Ramage  wrote:

Hello again,

I feel really stupid.

So I had set imap_user/pass, but not smtp_url so I was receiving emails
fine, but then instead of sending them, it was just encrypting them and
saving them via `set record = "+[Gmail]/Sent Mail"`.

** face palm **

Thanks for your help!



Glad to hear it’s working now. I thought sending/receiving was not the 
problem, so my focus was on GnuPG.


Just a side note, you don’t need the imap and smtp USE-flags in your 
package.use/neomutt file. None of the NeoMutt ebuilds in tree will 
honour it because >=neomutt-20170602 always build those features, look 
at [1][2] and `neomutt -v`.


Also it seems you use NeoMutt 20171208 which has some regressions, so 
consider an update to not run into the next unnecessary issue.



References:
 - [1] 
 - [2] 


--
Regards,
floyd

Re: [gentoo-user] chromium build failure

[allan gottlieb]

On Wed, Jan 31 2018, Canek Peláez Valdés wrote:

> On Wed, Jan 31, 2018 at 1:29 PM, allan gottlieb  wrote:
> [snip]
>> I have two questions, one trivial, one hopefully easy.
>>
>> 1. (trivial) In your recipe did you mean "rsync", not "sync"?
>
> I sync ("emerge --sync") only one machine, and then I rsync from there to
> my other computers. After the rsync is done, you need to do "emerge
> --metadata" in the recipient machine (--sync does that for you
> automatically).

So sync referred to an emerge command and when you copied files from
machine to machine you used rsync.  Thanks.
>
>> 2. I have a number of quickpkgs built.  Is it needed that
>>they all be updated and some removed or can I just do
>>the following command
>>
>>rsync -Pvase ssh machine1:/var/portage/packages/www-client \
>>  /var/portage/packages
>>
>>Notes: I use /var not /usr for portage
>>   machine2 has no dir /var/portage/packages/www-client
>
> I honestly don't know. There is a /usr/portage/packages/Packages with a lot
> of meta information, and I'm not 100% sure whether is absolutely required.
> Then again, creating binary packages is so fast that I usually delete
> /usr/portage/packages after updating my non-compiling machines. I know of
> people who maintain a large repository of binary packages (they can be
> built automatically with FEATURES="buildpkg" in make.conf), but I just
> create them when needed.

I have FEATURES="buildsyspkg" on all machines for safety.
It has worked in the sense that I have never needed to use
the resulting packages.

But I see your point that /var/portage/packages/Packages
may need to be updated on the target machine so it is probably
best to do your rsync of all of /var/portage/packages
>
> Regards.
> --
> Dr. Canek Peláez Valdés

thanks,
allan

Re: [gentoo-user] chromium build failure

[Neil Bothwick]

On Wed, 31 Jan 2018 15:38:27 -0600, Canek Peláez Valdés wrote:

> I sync ("emerge --sync") only one machine, and then I rsync from there
> to my other computers. After the rsync is done, you need to do "emerge
> --metadata" in the recipient machine (--sync does that for you
> automatically).

If you run the rsync daemon on the machine you --sync, you can set that
as the source for the other computers and emerge --sync on them, which
saves the extra step of updating the metadata.


-- 
Neil Bothwick

Men who go out with flat chested woman have reasons for feeling down


pgphioJRq5zKg.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] chromium build failure

[Canek Peláez Valdés]

On Wed, Jan 31, 2018 at 1:29 PM, allan gottlieb  wrote:
[snip]
> I have two questions, one trivial, one hopefully easy.
>
> 1. (trivial) In your recipe did you mean "rsync", not "sync"?

I sync ("emerge --sync") only one machine, and then I rsync from there to
my other computers. After the rsync is done, you need to do "emerge
--metadata" in the recipient machine (--sync does that for you
automatically).

> 2. I have a number of quickpkgs built.  Is it needed that
>they all be updated and some removed or can I just do
>the following command
>
>rsync -Pvase ssh machine1:/var/portage/packages/www-client \
>  /var/portage/packages
>
>Notes: I use /var not /usr for portage
>   machine2 has no dir /var/portage/packages/www-client

I honestly don't know. There is a /usr/portage/packages/Packages with a lot
of meta information, and I'm not 100% sure whether is absolutely required.
Then again, creating binary packages is so fast that I usually delete
/usr/portage/packages after updating my non-compiling machines. I know of
people who maintain a large repository of binary packages (they can be
built automatically with FEATURES="buildpkg" in make.conf), but I just
create them when needed.

Regards.
--
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

[gentoo-user] Grub2 boot problem

[Magnus Johansson]

Hello.

I've got a fresh Gentoo installation that does not boot. I just end up in
the Grub2 shell.

However when there if I do 'set root=(md/0)' and 'configfile
/grub/grub.cfg' I do get to the Grub2 menu where Gentoo boots just fine.

/boot and / are both on mdadm devices.

I've tried re-running grub-mkconfig and grub-install several times without
luck.

I've added domdadm to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub.

Drives sda/sdb use GPT disklabels and have 20M BIOS boot partitions first.

Thanks!

Re: [gentoo-user] chromium build failure

[allan gottlieb]

On Wed, Jan 24 2018, Canek Peláez Valdés wrote:

> On Wed, Jan 24, 2018 at 10:11 PM, allan gottlieb  wrote:
>>
>> I ran the build failed twice, each time with MAKEOPTS="--jobs=1" and the
>> build logs are essentially identical.  After about 12 hours compiling and
>> 36MB of build.log, the error shown below occurs
>>
>> I have two laptops with *very* similar gentoo distributions.  The newer
>> machine had a successful build first try.  The second older (4 years)
>> machine had both failures.  Each machine has profile
>> default/linux/amd64/17.0/desktop/gnome/systemd
>
> If the USE flags for chromium on both machines are the same, simply create
> a binary package from the machine that already built it.
>
> machine1:
>
> $ quickpkg --include-config=y www-client/chromium
>
> machine2
>
> $ sync --delete -Pvase ssh machine1:/usr/portage/packages/
> /usr/portage/packages/
> $ emerge --nodeps -1Kv www-client/chromium

Canek,

Again thank you for your recipe.

I have two questions, one trivial, one hopefully easy.

1. (trivial) In your recipe did you mean "rsync", not "sync"?

2. I have a number of quickpkgs built.  Is it needed that
   they all be updated and some removed or can I just do
   the following command

   rsync -Pvase ssh machine1:/var/portage/packages/www-client \
 /var/portage/packages

   Notes: I use /var not /usr for portage
  machine2 has no dir /var/portage/packages/www-client

Thanks in advance,
allan

Re: [gentoo-user] NeoMutt and GnuPG

[Lucas Ramage]

Hello again,

I feel really stupid.

So I had set imap_user/pass, but not smtp_url so I was receiving emails
fine, but then instead of sending them, it was just encrypting them and
saving them via `set record = "+[Gmail]/Sent Mail"`.

** face palm **

Thanks for your help!

Re: [gentoo-user] New install .. no high res console during boot.

[Corbin Bird]

On 01/31/2018 07:38 AM, Harry Putnam wrote:
> Setup:
> Installing gentoo-17 as guest in Vbox vm on solaris-11 HOST 
>(openindiana (powered by Illumos))
>
> VBox 5.6.2
> Kernel-4.15.0
> grub2
>
> I'm a litte confused about how to enable a high res framebuffer
> console.
>
> At gentoo pages:
> https://wiki.gentoo.org/wiki/Xorg/Guide#Kernel_modesetting
>
> I've followed the directions there as far as I could.
>
> lspci on a chroot does not show a driver for the:
>   Innotek Systemberatung Gmbh VirtualBox Graphics Adapter.
>
> And I find nothing about Innotek searching with '/' in menuconfig.
> So could not make any specific settings like those shows on the gentoo
> wiki pages for nVidia and AND/ATI
>
> Other pages such as https://wiki.gentoo.org/wiki/Fbsplash seem to
> indicate I would need to create an initramfs.
>
> The first page cited near the top of post .. tells you NOT to set some
> of the things the citation containing fbsplash (above) tell you to set.
>
> Such as  <*> Userspace VESA VGA
>  [*] Vesa VGA
>
> Is something outdate in one of those pages?
>
> Can someone using the kernel framebuffer explain how to do it on
> gentoo guest of vm?
>
>
>
.
Searched for that "device" and found a few interesting links:
> https://askubuntu.com/questions/435940/do-i-need-linux-drivers-for-virtual-box
> https://www.virtualbox.org/manual/ch04.html
.
If Linux has no access to the actual hardware ... the old "VGA=" hex
codes might work :
> https://www.linuxquestions.org/questions/debian-26/lilo-vga-modes-152575/
I have never tried the codes on "Userspace VESA VGA".
Might want to leave that out for a test run.

.
Corbin 

Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Rich Freeman]

On Wed, Jan 31, 2018 at 7:07 AM, Nikos Chantziaras  wrote:
>
> I was under the impression that it's the function that performs the call
> that needs protection. The called function doesn't need protection, because
> if it ends up being actually called, then it's too late already.
>
> For example, if sandboxed, untrusted code wants to speculatively execute a
> memcpy(), then the sandbox would need to call it on behalf of the untrusted
> code. But if the sandbox is protected, the memcpy() call would never be made
> speculatively, since retpoline will trap it. So memcpy() itself doesn't need
> protection. If memcpy() ends up being called, then it's too late. Protecting
> memcpy() doesn't do anything to prevent memcpy() from being called, as it's
> been called already.
>

I think there is some confusion here because in your scenario there
are actually 3 calls being made, and the sandbox is both being called,
and issuing a call.

In your scenario the code executing inside the sandbox calls an API in
the sandbox which in turn calls memcpy.

Code can be vulnerable to Spectre even if it doesn't call anything at
all (variant 2 of Spectre in particular does require a call, variant 1
does not, and who knows what other variants will be discovered in the
future).

In any case, the issue is that your untrusted code inside the sandbox
is calling trusted code via the sandbox API, and it is the sandbox API
that requires protection, as this is where there is a privilege
boundary.

Again, Spectre is not limited to code running in sandboxes.  Your ssh
server could be vulnerable to an incoming ssh client connection if the
client is colluding with another process on the same physical CPU,
assuming your ssh server contains vulnerable code.  Sandboxes are just
a particularly nasty and obvious target of this attack since they
routinely execute untrusted code on the same hardware as the software
being protected from the code.

However, this isn't a reason to just go rebuilding everything with
gcc-7.3 and assuming all is fine.  The maintainers of the upstream
projects really need to assess their code for vulnerabilities, and
treat gcc as a tool that might help solve things.


-- 
Rich

Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Rich Freeman]

On Wed, Jan 31, 2018 at 4:16 AM, Nikos Chantziaras  wrote:
> On 30/01/18 23:43, Rich Freeman wrote:
>>
>> If you had some program that listened on a socket and accepted a
>> length and a string and then did a bounds check using the length, it
>> might be exploitable if a local process could feed it data.  Even if
>> the process only listened for outside connections it might be
>> vulnerable if a local process colluded with a remote host to make that
>> connection.
>
>
> Well, if you're running a local process that is trying to attack you, you've
> been compromised already, imo.
>
> Local processes are always trusted.

Not at all.  This is the whole point of uids on linux and any POSIX
OS.  There is separation of privilege.

I should be able to give you ssh access to my database server using a
UID different from my database server, and it should be impossible for
you to damage my database (particularly if I am using resource
limits/etc).

Spectre allows local processes to probe the cache to obtain data
leaked from other processes running under different UIDs (or even the
kernel) which they should not have access to.

If MariaDB has vulnerable code listening on its socket, and you can
talk to that socket, and run code under a different UID, then you
could in theory read arbitrary data from MariaDB's memory.  That could
include tables you don't otherwise have privileges to read, or
possibly even credentials stored in memory that could allow you to
connect to the server and execute arbitrary queries.

Also, all this is requires is code running on the same CPU.  It could
be in a different VM, or a different container.

However, I wouldn't completely neglect local priv escalation attacks.
Sure, every sysadmin would prefer to not have code running on their
server that they didn't put there, but there is still such a thing as
defense in depth.  There is a reason we don't run all our daemons as
root.  If your server's ntp client somehow has a vulnerability and now
there is malicious code running under the ntp UID, it would still be
preferable that this code STAY contained in the ntp UID vs having
access to more mission-critical processes on the server.  Sure, you
will still want to wipe the server and install a clean one, but it
would be nice if you could do that after migrating your production
database/website/whatever to another server, versus having to revert
to the last backup.

--
Rich

[gentoo-user] New install .. no high res console during boot.

[Harry Putnam]

Setup:
Installing gentoo-17 as guest in Vbox vm on solaris-11 HOST 
   (openindiana (powered by Illumos))

VBox 5.6.2
Kernel-4.15.0
grub2

I'm a litte confused about how to enable a high res framebuffer
console.

At gentoo pages:
https://wiki.gentoo.org/wiki/Xorg/Guide#Kernel_modesetting

I've followed the directions there as far as I could.

lspci on a chroot does not show a driver for the:
  Innotek Systemberatung Gmbh VirtualBox Graphics Adapter.

And I find nothing about Innotek searching with '/' in menuconfig.
So could not make any specific settings like those shows on the gentoo
wiki pages for nVidia and AND/ATI

Other pages such as https://wiki.gentoo.org/wiki/Fbsplash seem to
indicate I would need to create an initramfs.

The first page cited near the top of post .. tells you NOT to set some
of the things the citation containing fbsplash (above) tell you to set.

Such as  <*> Userspace VESA VGA
 [*] Vesa VGA

Is something outdate in one of those pages?

Can someone using the kernel framebuffer explain how to do it on
gentoo guest of vm?

Re: [gentoo-user] UEFI-fails to boot

[J. Roeleveld]

On Sunday, January 28, 2018 11:35:33 AM CET Dan Johansson wrote:
> On 28.01.2018 00:13, Corbin Bird wrote:
> 
> Thanks for your feedback.
> 
> > .
> > Thank you for that info.
> > .
> > What kind of integrated VGA?
> > ( example Intel i915, i965, etc. )
> 
> According to the MB docu is it a "ASPEED AST2400 BMC" Video controller.
> 
> > .
> > The reason I ask is that the EFI framebuffer you have enabled should be
> > built into a specific video driver.
> > My system has an "amdgpu" video card.
> > The EFI framebuffer driver for the console is enabled.
> > The specific video driver called "amdgpu" is also enabled.
> > The EFI framebuffer is built as a sub-component of the specific video
> > driver "amdgpu".
> > .
> > 
> > Sample dmesg output :
> >> [6.223405] [drm] amdgpu kernel modesetting enabled.
> >> [6.223573] [drm] initializing kernel modesetting (POLARIS10
> >> 0x1002:0x67DF 0x1682:0x9480 0xC7)
> >> [6.882691] Console: switching to colour frame buffer device 240x67
> >> [6.900623] amdgpu :01:00.0: fb0: amdgpudrmfb frame buffer device
> > 
> > .
> > If you haven't already run this command, please do so :  lspci | grep -i
> > VGA
> # lspci | grep VGA
> 06:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED
> Graphics Family (rev 30)
> 
> > If the video device is a 'Aspeed AST', the version number of the
> > kernel you are using makes a big difference.
> 
> # uname -r
> 4.9.76-gentoo-r1
> 
> >>   ASPEED's AST2500 Display To Be Supported By Linux 4.11's DRM
> >> 
> >> https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/x-org-> 
> >> >> drm/935002-aspeed-s-ast2500-display-to-be-supported-by-linux-4-11-s-drm
> Thanks for that link, I will have to look into that.
> Although I will not be using X on this box, as it is a server, it looks
> like I need to configure DRM.

On a system with the same mainboard:

zcat /proc/config.gz | grep -i drm
# CONFIG_DRM is not set


Eg, DRM is not necessary.

I don't reboot often enough to find it necessary to "fix" the UEFI boot. Mine 
still goes into the EFI-shell and from there I start xen.

--
Joost

[gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Martin Vaeth]

Nikos Chantziaras  wrote:
>
> For example, if you don't trust Firefox, don't install Firefox. But you
> *do* trust Firefox. What you don't trust is the JS code Firefox is
> executing.

That's an artificial distinction, because it is actually firefox
which is executing the code during the interpretation of JS.

> So Firefox needs protection.

The only "protection" firefox could be giving is that interpreted
JS is not able to do anything (not access any file or any program
outside of a well-defined sandbox). For various reasons, this is
not the case and will not be the case in any foreseeable future.

What does need protection is all the programs which can be accessed
(almost no matter how indirectly) by JS code - which is almost everything
running on a typical desktop.

Admittedly, firefox can help by e.g. making it harder to use timers
for the precise time measurement needed for "simple" spectre exploits.
This is already happening, but this is independent of the mitigations
provided by the compiler.

> I was under the impression that it's the function that performs the call
> that needs protection. The called function doesn't need protection,
> because if it ends up being actually called, then it's too late already.

The opposite is true. There should be no problem for any code (even
untrusted) to query gnupg to verify the validity of the signature.
But with the spectre exploits, this query might be used to get the
secret key which gnupg must access. So it is gnupg which needs the
protection (unless you want to make it much harder to use gnupg).

> For example, if sandboxed, untrusted code wants to speculatively execute
> a memcpy(), then the sandbox would need to call it on behalf of the
> untrusted code.

In my above example, it is gnupg which speculatively executes some code
if queried e.g. to verify a signature. The "attacking" program then might
use this fact (under some conditions) to understand which secret key was
used.
Everything which untrusted code can influence (no matter how indirectly)
is possible subject to be exploited if it uses speculative execution.
Therefore, the only way to be on the safe side is to avoid speculative
execution altogether.

> But if the sandbox is protected, the memcpy() call would
> never be made speculatively, since retpoline will trap it.

This means that the sandbox-code itself is protected from being
"read" by other code. But already if e.g. a webpage uses libjpeg to
render a picture (even if it would do it inside of an otherwise
protected sandbox), and libjpeg uses speculative execution (which
it does if you do not have compiled it with the new compiler switches),
javascript might (theoretically) be used to get image data it normally
has no access to.

Admittedly, this is all very theoretical and whether it is
actually possible to write working exploits is a different story
(that's why I wrote "(under some conditions)" and "(theoretically)"):
Not every speculative execution actually _can_ be exploited,
but there is always a certain probability (the more direct the
victim program can be accessed by the thief code, the higher the
probability is).

[gentoo-user] kernel choices for booting gentoo as guest in vbox vm

[Harry Putnam]

Installing gentoo as guest into vbox vm on solaris-11 (openindiana)
HOST
gentoo-17
VBox 5.2.6
Kernel 4.15.0

My first boot resulted in resulted in a kernel panic... not able to
mount root.

I checked my /etc/fstab trying to make sure I didn't make a stupid
mistake there... it appear to be sound. (Included at the end of post)

I suspect it may be the result of a kernel choice... or rather the
lack of one.  Something that would have been able to mount /

I thought it would be ata_piix and made sure that was selected in
kernel .config

I'm thinking it may be be ata_generic, which I did not have selected.
Which I have now enabled.  But I see now, that is for IDE.

In a chroot now I can see lspci -k shows ata_piix in use .. but that
would probably be because in vbox I have the gentoo install media on
IDE secondary master.  But also shows sata controller ahci

Which I do also have selected in .config.  However there a number of
AHCI choices in the kernel config that were not selected.

Can anyone tell me what they used to allow gentoo in vbox to boot?

Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Mick]

On Wednesday, 31 January 2018 12:20:51 GMT Nikos Chantziaras wrote:
> On 31/01/18 14:04, Mick wrote:
> > Just to dilute my confusion on what I should do to keep desktops safe(r),
> > would someone please clarify:
> > 
> > Is it necessary to keyword gcc 7.3 + kernel 4.15 and emerge kernel 4.15
> > with gcc 7.3, or wait until these versions have been stabilised in the
> > tree?
> > 
> > What gcc version shall I use to update @world from then on?
> > 
> > PS. Some desktops are Intel, some are AMD and I also have 3-4 devices with
> > ARM in them ...
> 
> At the moment, you do need GCC 7.3. However, there is talk about these
> new flags being ported to GCC 6 and possibly even older versions.
> 
> As for the kernel, you don't need 4.15. 4.14 is the latest LTS kernel,
> and it has the needed patches. I think 4.9 (the previous LTS kernel) has
> them too.
> 
> Currently, once you enable CONFIG_RETPOLINE in the kernel config and
> rebuild with GCC 7.3, you should have all currently available kernel
> mitigations. Which currently are:
> 
>$ cat /sys/devices/system/cpu/vulnerabilities/*
>Mitigation: PTI
>Vulnerable
>Mitigation: Full generic retpoline
> 
> However, improvements to these mitigations will from now on happen for
> kernel 4.16 first and backported later. 4.16 for example got mitigations
> for ARM. It's how kernel upstream works; new stuff is done in the
> current development version, and backported later to still supported
> versions.

Thanks Nikos, I'm presently on 4.14.14, so I can update this to 4.14.15 and 
compile it with gcc-7.3;  then pick up future improvements as part of gentoo-
sources updates when kernels start being marked as stable.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Nikos Chantziaras]

On 31/01/18 14:04, Mick wrote:

Just to dilute my confusion on what I should do to keep desktops safe(r),
would someone please clarify:

Is it necessary to keyword gcc 7.3 + kernel 4.15 and emerge kernel 4.15 with
gcc 7.3, or wait until these versions have been stabilised in the tree?

What gcc version shall I use to update @world from then on?

PS. Some desktops are Intel, some are AMD and I also have 3-4 devices with ARM
in them ...


At the moment, you do need GCC 7.3. However, there is talk about these 
new flags being ported to GCC 6 and possibly even older versions.


As for the kernel, you don't need 4.15. 4.14 is the latest LTS kernel, 
and it has the needed patches. I think 4.9 (the previous LTS kernel) has 
them too.


Currently, once you enable CONFIG_RETPOLINE in the kernel config and 
rebuild with GCC 7.3, you should have all currently available kernel 
mitigations. Which currently are:


  $ cat /sys/devices/system/cpu/vulnerabilities/*
  Mitigation: PTI
  Vulnerable
  Mitigation: Full generic retpoline

However, improvements to these mitigations will from now on happen for 
kernel 4.16 first and backported later. 4.16 for example got mitigations 
for ARM. It's how kernel upstream works; new stuff is done in the 
current development version, and backported later to still supported 
versions.

[gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Nikos Chantziaras]

On 31/01/18 13:17, Martin Vaeth wrote:

Nikos Chantziaras  wrote:


Well, if you're running a local process that is trying to attack you,
you've been compromised already, imo.


By your definition, you are compromised if you surf to the
wrong webpage with enabled javascript.


That's not what was said.

What was said is that software that executes untrusted code inside a 
trusted container is affected. You trust the container mechanism, you 
don't trust the code executing inside of it. So the container needs to 
be protected.


For example, if you don't trust Firefox, don't install Firefox. But you 
*do* trust Firefox. What you don't trust is the JS code Firefox is 
executing. So Firefox needs protection.




You misunderstand: For the packages which run the code, the mitigations
like retpoline do not help much. It is the packages which _somehow_
react (or can be called) by such a code which need the protection by
retpoline built-in.
And this is an awful lot of packages since it includes also all libraries
which are possibly used by these packages, language interpreters used by
these packages, etc.  If in doubt, I would re-emerge the
full -e @world with corresponding compiler switches enabled.


I was under the impression that it's the function that performs the call 
that needs protection. The called function doesn't need protection, 
because if it ends up being actually called, then it's too late already.


For example, if sandboxed, untrusted code wants to speculatively execute 
a memcpy(), then the sandbox would need to call it on behalf of the 
untrusted code. But if the sandbox is protected, the memcpy() call would 
never be made speculatively, since retpoline will trap it. So memcpy() 
itself doesn't need protection. If memcpy() ends up being called, then 
it's too late. Protecting memcpy() doesn't do anything to prevent 
memcpy() from being called, as it's been called already.


What am I missing here? :-P

Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Mick]

On Wednesday, 31 January 2018 11:30:13 GMT Martin Vaeth wrote:
> Nikos Chantziaras  wrote:
> > Yeah, that's the kind of software that benefits from the Spectre
> > mitigation patches. Like browsers, virtualization or emulation software,
> > the kernel, etc.
> 
> No. It's software like gnupg, encfs, openssl and all the library they
> use (glibc, glib, X etc) which need these patches.
> 
> > Rebuilding the whole system with these flags on doesn't sound like a
> > good idea. Now, I don't know if it would hurt anything, but it's not
> > uncommon for build flags to break random stuff.
> 
> Yep. On x86, gcc cannot compile itself if built with -fno-plt.
> 
> > I haven't seen any word from anyone yet as to whether these flags are
> > actually recommended or not on a system-wide basis.
> 
> Actually, it is not even clear in the moment which flags should be
> used in which settings. (There has been some discussion in the
> gentoo forums but to no completely satisfactory result yet.)
> 
> > So my educated guess is: No. Don't do that.
> 
> Yes and no: It is probably recommended, but the flags are so no and
> so poorly understood that people are hesitating with recommendations.
> Also, spectre is hard to exploit, so it is perhaps better to wait in
> the moment until some experience ins there.
> 
> > If a package is affected, it
> > stands to reason that the upstream of that package would change their
> > build system to use these new flags where needed.
> 
> No, for many reasons:
> 
> 1. Packages often try to not add any flags; especially in gentoo it is a
> policy that they _must_ not: If they do, it would get patched out in gentoo.
> 
> 2. A library has no idea what it is used for. Why should it add something,
> only because some program using it should be protected?
> 
> 3. Adding the flags slows down the programs. It is the user who must
> decide whether patches are desirable for his use case and architecture.
> (Maybe this is less relevant know but in a while when versions of
> processors "immune" to spectre come out.)

Just to dilute my confusion on what I should do to keep desktops safe(r), 
would someone please clarify:

Is it necessary to keyword gcc 7.3 + kernel 4.15 and emerge kernel 4.15 with 
gcc 7.3, or wait until these versions have been stabilised in the tree?

What gcc version shall I use to update @world from then on?

PS. Some desktops are Intel, some are AMD and I also have 3-4 devices with ARM 
in them ...
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Martin Vaeth]

Nikos Chantziaras  wrote:
> Yeah, that's the kind of software that benefits from the Spectre
> mitigation patches. Like browsers, virtualization or emulation software,
> the kernel, etc.

No. It's software like gnupg, encfs, openssl and all the library they
use (glibc, glib, X etc) which need these patches.

> Rebuilding the whole system with these flags on doesn't sound like a
> good idea. Now, I don't know if it would hurt anything, but it's not
> uncommon for build flags to break random stuff.

Yep. On x86, gcc cannot compile itself if built with -fno-plt.

> I haven't seen any word from anyone yet as to whether these flags are
> actually recommended or not on a system-wide basis.

Actually, it is not even clear in the moment which flags should be
used in which settings. (There has been some discussion in the
gentoo forums but to no completely satisfactory result yet.)

> So my educated guess is: No. Don't do that.

Yes and no: It is probably recommended, but the flags are so no and
so poorly understood that people are hesitating with recommendations.
Also, spectre is hard to exploit, so it is perhaps better to wait in
the moment until some experience ins there.

> If a package is affected, it
> stands to reason that the upstream of that package would change their
> build system to use these new flags where needed.

No, for many reasons:

1. Packages often try to not add any flags; especially in gentoo it is a
policy that they _must_ not: If they do, it would get patched out in gentoo.

2. A library has no idea what it is used for. Why should it add something,
only because some program using it should be protected?

3. Adding the flags slows down the programs. It is the user who must
decide whether patches are desirable for his use case and architecture.
(Maybe this is less relevant know but in a while when versions of
processors "immune" to spectre come out.)

[gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Martin Vaeth]

Nikos Chantziaras  wrote:
>
> Well, if you're running a local process that is trying to attack you,
> you've been compromised already, imo.

By your definition, you are compromised if you surf to the
wrong webpage with enabled javascript.

While this is arguably true, I would distinguish between various
degree of compromise and would prefer if nevertheless such webpages
would not be able to e.g. read the secret keys of a running gnupg
process.

> So, unless you're running some kind of server that offers execution time
> to clients

... or use your browser with not always disabled javascript ...

> and the few packages that run untrusted code.

You misunderstand: For the packages which run the code, the mitigations
like retpoline do not help much. It is the packages which _somehow_
react (or can be called) by such a code which need the protection by
retpoline built-in.
And this is an awful lot of packages since it includes also all libraries
which are possibly used by these packages, language interpreters used by
these packages, etc.  If in doubt, I would re-emerge the
full -e @world with corresponding compiler switches enabled.

Of course, rebuilding @world without changing your C*FLAGS before
would be pointless.

[gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Nikos Chantziaras]

On 31/01/18 11:48, taii...@gmx.com wrote:

On 01/31/2018 04:16 AM, Nikos Chantziaras wrote:


On 30/01/18 23:43, Rich Freeman wrote:

If you had some program that listened on a socket and accepted a
length and a string and then did a bounds check using the length, it
might be exploitable if a local process could feed it data. Even if
the process only listened for outside connections it might be
vulnerable if a local process colluded with a remote host to make that
connection.


Well, if you're running a local process that is trying to attack you, 
you've been compromised already, imo.


Local processes are always trusted. If Spectre is a vulnerability that 
can be exploited by trusted code, it's not really a vulnerability. 
Trusted code is called "trusted" for a reason.
I wouldn't classify for instance running a multiplayer game in a VM as 
"trusted" code, the whole point of hardware virtualization is that you 
don't have to trust what is being executed there.


Not to mention the issue with most websites requiring javascript for no 
reason to function properly.


Yeah, that's the kind of software that benefits from the Spectre 
mitigation patches. Like browsers, virtualization or emulation software, 
the kernel, etc.


Rebuilding the whole system with these flags on doesn't sound like a 
good idea. Now, I don't know if it would hurt anything, but it's not 
uncommon for build flags to break random stuff.


I haven't seen any word from anyone yet as to whether these flags are 
actually recommended or not on a system-wide basis. The GCC patches were 
primarily developed for the kernel, but there was no word about whether 
or not people should build all their software with these flags or not.


So my educated guess is: No. Don't do that. If a package is affected, it 
stands to reason that the upstream of that package would change their 
build system to use these new flags where needed.


But as always: I could be wrong :-)

Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[taii...@gmx.com]

On 01/31/2018 04:16 AM, Nikos Chantziaras wrote:


On 30/01/18 23:43, Rich Freeman wrote:

If you had some program that listened on a socket and accepted a
length and a string and then did a bounds check using the length, it
might be exploitable if a local process could feed it data. Even if
the process only listened for outside connections it might be
vulnerable if a local process colluded with a remote host to make that
connection.


Well, if you're running a local process that is trying to attack you, 
you've been compromised already, imo.


Local processes are always trusted. If Spectre is a vulnerability that 
can be exploited by trusted code, it's not really a vulnerability. 
Trusted code is called "trusted" for a reason.
I wouldn't classify for instance running a multiplayer game in a VM as 
"trusted" code, the whole point of hardware virtualization is that you 
don't have to trust what is being executed there.


Not to mention the issue with most websites requiring javascript for no 
reason to function properly.

Re: [gentoo-user] NeoMutt and GnuPG

[Floyd Anderson]

On Wed, 31 Jan 2018 20:50:13 +1300
"Roger J. H. Welsh"  wrote:

On  Wed, Jan 31, 2018 at 05:17:45AM +0100 , Floyd Anderson wrote:


> On my neomutt, when I press "v" to view attachments, all I can
> see is text/plain. I think my neomutt does something automatic to
> decrypt the messages.
>

Indeed, viewing attachments encrypted would break many functions otherwise,
e.g. piping, printing, saving.

So Lucas's original problem sounds like an issue with this, I can only
imagine it is some sort of lack of pgp support.


Honestly, I did not comprehended Luca’s issue and therefore have no clue 
for the reason. Perhaps something with mixed and interfering USE-flags. 
IIRC, his prior Mutt installation works after some hiccups.



> My source docs I used when setting my gpg up with mutt were:
> https://gitlab.com/muttmua/mutt/wikis/MuttGuide/UseGPG
> http://codesorcery.net/old/mutt/mutt-gnupg-howto
>

In the meantime NeoMutt != Mutt, so not to forget to mention
. ;-)

Lol. Of course. I read that for my current setup. Though I never really
got to grips with what gpgme was, as I was more concerned with
bootstrapping a working (neo)mutt configuration, which is why I source
my : "14 ! long and cryptic command lines".


Similar here, for a long time I plan to fully switch my setup away from 
widely spread (more or less) static config files, to a more dynamic one 
using Lua. But it works fine and that is murder for the motivation.



Thanks for the critique Floyd.


You’re welcome.


--
Regards,
floyd

[gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Nikos Chantziaras]

On 30/01/18 23:43, Rich Freeman wrote:

If you had some program that listened on a socket and accepted a
length and a string and then did a bounds check using the length, it
might be exploitable if a local process could feed it data.  Even if
the process only listened for outside connections it might be
vulnerable if a local process colluded with a remote host to make that
connection.


Well, if you're running a local process that is trying to attack you, 
you've been compromised already, imo.


Local processes are always trusted. If Spectre is a vulnerability that 
can be exploited by trusted code, it's not really a vulnerability. 
Trusted code is called "trusted" for a reason.


So, unless you're running some kind of server that offers execution time 
to clients (the clients are untrusted then), there's not many instances 
of Spectre actually being relevant. Amazon and Google etc might be 
running around currently like headless chickens, but for desktop home 
users, Spectre does not seem to have far reaching implications once 
you've patched the kernel and the few packages that run untrusted code.