Re: Realizing Good Ideas with Debian Money

[Philipp Kern]

On 5/31/2019 11:04 PM, Luca Filipozzi wrote:
> Before you ask: an insecure hypervisor is an insecure buildd.

Are we then looking more closely at AMD-based machines given that those
had less problems around speculative attacks?

Kind regards
Philipp Kern

Re: Buster/XFCE unlock screen is blank

[Andreas Tille]

Hi Russ,

On Fri, May 31, 2019 at 06:32:52PM -0700, Russ Allbery wrote:
> (This probably belonged on debian-user, but since I have background on
> this specific problem and already did the research.)

While this seems to be a problem for debian-user its very sensible that
the issue was raised here as well.  I stumbled upon this issue on two
laptops and I consider this a serious issue for the Buster release that.
Users ending up with a black screen in a not so uncommon setup is
something we need to avoid.  I intended to write a bug report about this
soon.
 
> Raj Kiran Grandhi  writes:
> 
> > In a fresh install of Buster with XFCE desktop, locking the screen
> > blanks the monitor and the monitor enters a power save state. After
> > that, neither moving the mouse nor typing on the keyboard would turn
> > the monitor back on.
> 
> Ctrl-Alt-F7 will also restore the desktop (which I think is just another
> version of your solution 2 of switching VTs).
> 
> This appears to be a bug in light-locker specifically, which is the
> default screen lock program with XFCE with lightdm.  See, for instance:
> 
> https://github.com/the-cavalry/light-locker/issues/114
> 
> Switching to another greeter from the default gtk-greeter appears to help
> according to that bug, which may mean that the bug is actually in
> lightdm-gtk-greeter.  There doesn't appear to be a Debian bug for this; it
> might be a good idea to open one against light-locker (or, if you confirm
> switching to slick-greeter per that bug, lightdm-gtk-greeter).

Yes, please file the bug (and may be report the bug number here).  We
should not release with a broken greeter as default since we can not
assume that normal users will find out the "switch VT trick" and instead
will assume the box is frozen. 

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: Buster/XFCE unlock screen is blank

[Raj Kiran Grandhi]

> > Switching to another greeter from the default gtk-greeter appears to help
> > according to that bug, which may mean that the bug is actually in
> > lightdm-gtk-greeter.  There doesn't appear to be a Debian bug for this; it
> > might be a good idea to open one against light-locker (or, if you confirm
> > switching to slick-greeter per that bug, lightdm-gtk-greeter).

Switching to slick-greeter helped. Thank you.

>
> Yes, please file the bug (and may be report the bug number here).  We
> should not release with a broken greeter as default since we can not
> assume that normal users will find out the "switch VT trick" and instead
> will assume the box is frozen.

Thank you for the feedback. I have filed a bug report (929834) for this issue.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929834

Regards,
Raj Kiran

Re: Buster/XFCE unlock screen is blank

[Adam Borowski]

On Sat, Jun 01, 2019 at 11:06:42AM +0200, Andreas Tille wrote:
> > This appears to be a bug in light-locker specifically, which is the
> > default screen lock program with XFCE with lightdm.  See, for instance:
> > 
> > https://github.com/the-cavalry/light-locker/issues/114
> > 
> > Switching to another greeter from the default gtk-greeter appears to help
> > according to that bug, which may mean that the bug is actually in
> > lightdm-gtk-greeter.  There doesn't appear to be a Debian bug for this; it
> > might be a good idea to open one against light-locker (or, if you confirm
> > switching to slick-greeter per that bug, lightdm-gtk-greeter).
> 
> Yes, please file the bug (and may be report the bug number here).  We
> should not release with a broken greeter as default since we can not
> assume that normal users will find out the "switch VT trick" and instead
> will assume the box is frozen. 

While I greatly prefer slick-greeter (I use it exclusively since the first
day I reviewed+sponsored the package), I recall it doesn't support a11y
anywhere as well as the default greeter.  This is old data, though -- as my
wetware doesn't require a11y, I wouldn't even know what to look at.

But, the culprit is light-locker.  In general, it's in such a buggy state
that I believe it shouldn't be in the distribution at all, much less a
default of any kind.  After it replaced xscreensaver[1] as the xfce's
dependency, I went into some pretty heated arguments, but then stormed off
and ignored the issue.

Just some issues with light-locker.  INACCURATE, BASED ON AN OLD VERSION,
AND NOT RESEARCHED WELL AT ALL.  (Ie, areas to look at, not proper reports)
* it doesn't show anyone is logged in -- lock screen is pixel-to-pixel
  identical as the login screen
* breaks when the *DM is not lightdm.  A package dependency doesn't mean
  that lightdm is running or used to start that session.
* breaks with multiseat (as in: concurrent same-uid logins from different
  seats, not the systemd meaning)
* breaks if ssh -X into the box is used with some programs
* breaks with any non-standard VT assignment
(Some of the issues might have been already fixed.)

At the time of the xscreensaver debacle, there was no sane alternative
(candidates depended on 80% of GNOME, offered no feedback nor discoverable
controls to the user, etc).  There _is_ a wonderful alternative now:
xfce4-screensaver, which seems to work perfectly[2] -- but alas, it's not in
Buster.

Using unstable myself, I'm not sure what to recommend for Buster.  But if
the bugs can't get fixed in late freeze, and slick-greeter is not enough,
I's light-locker not the greeter I'd propose switching out of.


Meow!

[1]. When jwz planted a time-bomb in xscreensaver.
[2]. There was an issue with taking lots of CPU even when the monitor has
 been long since powered down, but that's now fixed.
-- 
⢀⣴⠾⠻⢶⣦⠀ Latin:   meow 4 characters, 4 columns,  4 bytes
⣾⠁⢠⠒⠀⣿⡁ Greek:   μεου 4 characters, 4 columns,  8 bytes
⢿⡄⠘⠷⠚⠋  Runes:   ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes
⠈⠳⣄ Chinese: 喵   1 character,  2 columns,  3 bytes <-- best!

Re: Buster/XFCE unlock screen is blank

[Jonathan Carter]

Hey Adam

On 2019/06/01 18:29, Adam Borowski wrote:
> At the time of the xscreensaver debacle, there was no sane alternative
> (candidates depended on 80% of GNOME, offered no feedback nor discoverable
> controls to the user, etc).  There _is_ a wonderful alternative now:
> xfce4-screensaver, which seems to work perfectly[2] -- but alas, it's not in
> Buster.

When I first filed the ITP for xfce4-screensaver I got some pushback (of
which I don't all disagree with). After some discussion and digging in
deeper into the issue the Debian Xfce team agreed that it can be
maintained as part of the Xfce team. At freeze time it was still in
alpha and had some show-stopper issues, we decided that it would be best
for everyone not to have that in buster at that time. There are also
still some integration issues that are still outstanding. Overall it
just wasn't ready for buster in time, but I'll be happy to work on a
backport for buster when some of the last few issues have been resolved.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Buster/XFCE unlock screen is blank

[Holger Levsen]

On Sat, Jun 01, 2019 at 06:29:31PM +0200, Adam Borowski wrote:
> Using unstable myself, I'm not sure what to recommend for Buster.  

https://tracker.debian.org/pkg/physlock


signature.asc
Description: PGP signature

Re: Buster/XFCE unlock screen is blank

[Russ Allbery]

Adam Borowski  writes:

> But, the culprit is light-locker.  In general, it's in such a buggy
> state that I believe it shouldn't be in the distribution at all, much
> less a default of any kind.  After it replaced xscreensaver[1] as the
> xfce's dependency, I went into some pretty heated arguments, but then
> stormed off and ignored the issue.

It's worth noting here that xscreensaver has an IMO serious security
vulnerability (unless maybe this has been fixed?): because it doesn't
integrate properly with the desktop, it doesn't hide desktop
notifications.  Desktop notifications will appear above the lock screen.
If you therefore leave a locked computer in some relatively public place
(such as an open plan office at work), you may be exposing things on your
screen that you didn't expect, such as direct messages from some messaging
system that's plugged into desktop notifications.

I did some research on that a while back and ended up not filing a bug
about it because it looked relatively pointless.  It appeared to be a deep
design choice on both sides, and not something anyone was likely to solve,
so I just switched to a desktop-aware locker.

-- 
Russ Allbery (r...@debian.org)   

Re: Buster/XFCE unlock screen is blank

[gregor herrmann]

On Sat, 01 Jun 2019 11:04:28 -0700, Russ Allbery wrote:

> It's worth noting here that xscreensaver has an IMO serious security
> vulnerability (unless maybe this has been fixed?): because it doesn't
> integrate properly with the desktop, it doesn't hide desktop
> notifications.  

I can't reproduce this in a quick test:

Terminal 1: sleep 5 ; notify-send foo
Terminal 2: xscreensaver-command -lock

No "foo" notification pops up over the screensaver image.

(This is with awesome, maybe the story is different for desktop
environments.) 


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Supertramp: Some Things Never Change


signature.asc
Description: Digital Signature

Re: Buster/XFCE unlock screen is blank

[Russ Allbery]

gregor herrmann  writes:

> I can't reproduce this in a quick test:

> Terminal 1: sleep 5 ; notify-send foo
> Terminal 2: xscreensaver-command -lock

> No "foo" notification pops up over the screensaver image.

> (This is with awesome, maybe the story is different for desktop
> environments.) 

Yeah, I think it may be DE-related.  I ran into it with Xfce and, IIRC,
GNOME (although it would have been older GNOME).

-- 
Russ Allbery (r...@debian.org)   

Re: Buster/XFCE unlock screen is blank

[Georg Faerber]

Hi Russ, all,

On 19-06-01 11:04:28, Russ Allbery wrote:
> I did some research on that a while back and ended up not filing a bug
> about it because it looked relatively pointless.  It appeared to be a
> deep design choice on both sides, and not something anyone was likely
> to solve, so I just switched to a desktop-aware locker.

If I may ask, which one?

Cheers,
Georg


signature.asc
Description: PGP signature

Re: Realizing Good Ideas with Debian Money

[G. Branden Robinson]

At 2019-06-01T09:04:39+0200, Philipp Kern wrote:
> Are we then looking more closely at AMD-based machines given that
> those had less problems around speculative attacks?

To borrow a phrase from Christopher Hitchens, this comment gives a
hostage to fortune.

My team at work closely follows (and part of it contributes to) the
research in microarchitectural timing-channel attacks; we just covered
the white paper on one of the three new attacks (RIDL)[1] on Friday.

I'll say this now because I don't know of anything embargoed that could
get me into trouble: don't count on AMD's good smell just this second to
last.  Remember that the previous round of embarrassments
(Spectre/Meltdown) didn't entirely spare AMD and ARM, and we haven't yet
seen any ground-up reimplementations of CPU cores with publically
auditable, formally-verified proofs of immunity to microarchitectural
timing channel attacks.

I see no reason to reward AMD with purchases based on what may be an
accidental and temporary lack of egg on the face.  This is the same firm
that followed Intel into the land of unauditable system management
firmware[2] and acquired ATI and shut down the information channels
enabling good free video drivers to be developed[3].

My two cents[4] is that DSA should make its purchasing and hardware
solicitation decisions with the architectural security issue fairly far
down the priority list.  It saddens me to say that, but this new class
of exploits, what van Schaik et al. call "microarchitectural data
sampling" (MDS), is a playground for security researchers right now; a
big rock has been turned over and bugs are erupting from the soil in a
squamous frenzy.  It will take months or years for the situation to
settle down.

To acquire hardware based on what is known today is to risk buyer's
remorse.  Plan on inescapable remorse later; every chip vendor will let
us down until corporate managers learn to treat confidentiality and
integrity as feature rather than cost centers.  (And count on them to
forget what they've learned after a few quarters pass without
embarassing headlines.)

Some day, perhaps, if the universe is less than maximally cruel, we'll
have the option of server-class RISC-V systems with fully-documented,
formally-verified designs.  But that day is not yet here.

In the meantime, always keep a fork with some cooked crow on it ready to
hand, so that the next time you run into one of the many "pragmatic"
people in our community who puffed and blew about how we didn't "really
need" open hardware, you can invite them to eat the stuff and so be
silent.

One wonders how pragmatic they'll feel when it's _their_ private data
being exfiltrated.

[1] https://mdsattacks.com/files/ridl.pdf
[2] https://libreboot.org/faq.html#amd
[3] I don't have a good cite handy for this, but Michel Dänzer can
doubtless tell the story with more accuracy and precision than I
can.
[4] ...further discounted reflecting my rather low level of project
activity.


signature.asc
Description: PGP signature

Re: Survey: git packaging practices / repository format

[Nikolaus Rath]

On May 29 2019, Sam Hartman  wrote:
> I'm certainly going to look at dck-buildpackage now, because what he
> describes is a workflow I'd like to be using within Debian.
>
> For some projects I want to ignore orig tarballs as much as I can.  I'm
> happy with native packages, or 3.0 quilt with single-debian-patch.
> I don't want merge artifacts from Debian packaging on my branches.
> I'm happy to need to give the system an upstream tag.
> I'm happy for a dsc to fall out the bottom, and so long as it
> corresponds to my git tree I don't care how that happens.
> I have a slight preference for 3.0 format over 1.0 format packages.  3.0
> makes it possible to deal with binaries, better compression and a couple
> of things like that.  The quilt bits are (in this workflow) an annoyance
> to be conquered, not a value.
>
> The thing his approach really seems to have going for it is that he
> gives up on the debian history fast forwarding and instead rebases a lot
> for a cleaner history.
> If we could figure out a way to collaborate on something like that well,
> it might be a very interesting tool to have.

This sounds similar to the (now unmaintained) git-dpm to me.

Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Realizing Good Ideas with Debian Money

[Russ Allbery]

"G. Branden Robinson"  writes:

> My two cents[4] is that DSA should make its purchasing and hardware
> solicitation decisions with the architectural security issue fairly far
> down the priority list.  It saddens me to say that, but this new class
> of exploits, what van Schaik et al. call "microarchitectural data
> sampling" (MDS), is a playground for security researchers right now; a
> big rock has been turned over and bugs are erupting from the soil in a
> squamous frenzy.  It will take months or years for the situation to
> settle down.

> To acquire hardware based on what is known today is to risk buyer's
> remorse.  Plan on inescapable remorse later; every chip vendor will let
> us down until corporate managers learn to treat confidentiality and
> integrity as feature rather than cost centers.  (And count on them to
> forget what they've learned after a few quarters pass without
> embarassing headlines.)

+1 to this.  So far as I can tell, about the only thing that seems to
correlate with being less likely to have side-channel attacks is less
sophisticated scheduling pipelines and processor architecture (read:
simpler, slower processors).  And this area of security research is
changing very rapidly.  I would expect several more novel attacks to
surface.

Processors that don't have a bunch of non-free, unauditable bullshit as a
proprietary control plane would obviously be better, but you'd be paying a
prohibitive performance price (not to mention other issues).  There just
aren't any good options right now.  Buy (or accept donations of) whatever
makes sense for other reasons, and expect there to be mandatory microcode
updates, kernel and virtualization workarounds, and security bugs.

-- 
Russ Allbery (r...@debian.org)   

Re: Buster/XFCE unlock screen is blank

[Russ Allbery]

Georg Faerber  writes:
> On 19-06-01 11:04:28, Russ Allbery wrote:

>> I did some research on that a while back and ended up not filing a bug
>> about it because it looked relatively pointless.  It appeared to be a
>> deep design choice on both sides, and not something anyone was likely
>> to solve, so I just switched to a desktop-aware locker.

> If I may ask, which one?

light-locker, hence why I know about the bug that started this thread.  :)
(I never filed it as a bug since I didn't mind the workaround.  In
retrospect, I should have.)

Obviously given the discussion here I'm not sure I'd recommend that one.

-- 
Russ Allbery (r...@debian.org)   

Re: Survey: git packaging practices / repository format

[Ian Jackson]

Nikolaus Rath writes ("Re: Survey: git packaging practices / repository 
format"):
> On May 29 2019, Sam Hartman  wrote:
> > The thing his approach really seems to have going for it is that he
> > gives up on the debian history fast forwarding and instead rebases a lot
> > for a cleaner history.
> > If we could figure out a way to collaborate on something like that well,
> > it might be a very interesting tool to have.

The difficulty with this as a collaboration approach is that you can't
tell whether a rebase is "the newest", at least without a lot of
additional information.  That additional information is the "clutter"
if you like which the "cleaner" history doesn't contain.

> This sounds similar to the (now unmaintained) git-dpm to me.

Both git-debrebase and git-dpm use a special history structure to
record what the most recent rebase is.  Obviously I prefer
git-debrebase since I wrote it - using a different data model - even
after I knew about git-dpm and its data model.  But maybe this isn't
the thread for that advocacy conversation.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Buster/XFCE unlock screen is blank

[Theodore Ts'o]

On Sat, Jun 01, 2019 at 06:16:58AM +0530, Raj Kiran Grandhi wrote:
> 
> In a fresh install of Buster with XFCE desktop, locking the screen
> blanks the monitor and the monitor enters a power save state. After
> that, neither moving the mouse nor typing on the keyboard would turn
> the monitor back on.
> I could find two ways to get the display back on:
> 
> 1. Typing the password without any visual feedback (while the monitor
> continues to be in the power save state) unlocks the screen and the user
> session is displayed normally.
> 
> 2. Switching to another VT, say vt1 or vt2 turns the monitor back on
> and on switching
> back to the vt of the original session the unlock prompt is displayed
> normally and the screen can be unlocked.

There's another workaround (which is the one I use):

xset s off

This has other consequences as well, of course, but I tend to suspend
my laptop if it's ever going to be left alone, particularly if it's
running on battery.

And once I found a workaround which worked for my laptop, I was too
lazy to find a more "proper" fix.  :-)

- Ted

Re: Survey: git packaging practices / repository format

[Theodore Ts'o]

On Tue, May 28, 2019 at 04:51:10PM +0100, Ian Jackson wrote:
> 
>  Modified   Direct changes git merge
>   upstream files,to upstream files  (.dsc: 1.0-with-diff or
>  plus debian/*. single-debian-patch)
>  Maybe d/patches, depending.
>  History has direct merges from upstream.

There's a variant of this which is to grab updates from upstream using
"git cherry-pick -x COMMIT_ID ; git format-patch -o debian/patches -1 
COMMIT_ID".

At the moment I'm updating debian/patches/series by hand, but I really
should automate all of the above.

- Ted

Re: ZFS in Buster

[Theodore Ts'o]

On Tue, May 28, 2019 at 06:43:55PM +0200, Dan wrote:
> 
> The ZFS developers proposed the Linux developers to rewrite the whole
> ZFS code and use GPL, but surprisingly the linux developers didn't
> accept. See below:
> https://github.com/zfsonlinux/zfs/issues/8314

I've read the thread, and there are a lot of misunderstandings of many
of the key people involved.  There also seems to be a lot of
misunderstanding of what the cause of the "hostility" is coming from
--- it is *not* about "sticking it to Oracle because they chose the
CDDL".

Also, it's not accurate that "linux developers didn't accept".  Ryan
sent a query to Linus, and Linus didn't respond.  I don't know if he
sent a single message, or whether he retried a couple of times.  A
failure to respond is not the same as a rejection.  There are plenty
of reasons why Linus might not have responded.

That being said, I don't propose to relitigate that whole thread here.
If people really care, feel free to contact me privately.  Or it could
be the case that since Ryan has closed, the ZoL community has already
moved on.  Which is also a fine outcome: from most of the upstream
Linux developers that I've talked to; not because they hold any
particular animus against ZoL.  It's just that no one feels
particularly interested in giving ZoL any kind of special treatment
--- the hostility around bypassing the requirements of GPL is about
exactly that; not the identity of the company or project trying to do
those particular things.

As Sam has noted, even in the most permissive interpretation, which is
that the Kernel has chosen to draw the lines around GPL compliance in
a different place as the FSF, does not mean that there are *no* lines.
Indeed, there are lines, and when they are violated, there will be
hostility and a refusal to cooperate, and ZoL is getting no better
*or* no worse treatment in that regard.

Bringing this back to Debian, my perception is that while there is not
unanimity about how the moral and legal requirements of the GPL
should be understood within Debian (just as there is also not
unanimity in the kernel community), the center of gravity within
Debian tends to be weighted towards the less permissive
interpretations of the GPL compared to the Linux Kernel community as
whole.  Which is to say, if you can't get the Linux Kernel community
folks to agree towards a certain flexibility towards evading the
CDDL/GPL license compatibility problems using techniques like "GPL
condoms", it is even less likely that the Debian community is going to
be willing to be so accomodating.

I also agree with Sam that the only way to know for sure is to have a
GR.  So you don't have to take our word for it; but please do
understand it's going to take a lot of community resources to make
that determination.  And there might be better uses of that time and
energy.

Regards,

- Ted