Project

General

Profile

Feature #5684

Screen locker

Added by Tails over 4 years ago. Updated 22 days ago.

Status:
In Progress
Priority:
Elevated
Assignee:
Category:
-
Target version:
Start date:
12/03/2014
Due date:
% Done:

78%

QA Check:
Dev Needed
Feature Branch:
segfault:feature/5684-screen-locker
Type of work:
Code
Easy:
No
Affected tool:

Description

Tails is currently lacking a screen locker and this has been a frequent feature request. For example, as Tails is been adopted more and more by journalists, they want to be able to leave their computer unattended in their office to go to the toilets for a minute and have their screen locked.

This has also been mentioned as a requirement for Tails Server: https://tails.boum.org/blueprint/server_edition/

Team: sajolida, segfault, anonym

tails-lock.sh View (2.04 KB) segfault, 02/20/2016 09:33 PM

double password entry.png View (15.6 KB) sajolida, 02/21/2016 02:13 PM

tails_screen_locker.png View (10.7 KB) segfault, 04/01/2016 04:03 PM

triple-trouble.png View (11.5 KB) anonym, 11/28/2016 05:15 PM


Subtasks

Feature #5588: Do not create auto-login text consolesResolved

Feature #5589: Have a password-less amnesia account by defaultDuplicate

Feature #5878: Add a lock screen action to the system menuResolved

Feature #11256: Replace "Debian Live user" with a more descriptive full user nameResolved

Feature #6017: Ensure that the emergency shutdown works while the screen is lockedResolved

Feature #8385: Investigate if other distros are interested in our screen locking solutionResolved

Feature #8384: Investigate how other live/privacy distros do screen lockingResolved

Feature #8383: Research technical possibilities to implement a password prompt for screen lockingResolved

Bug #10970: Document screen lockerConfirmedspriver

Bug #12449: Fix multiple lock screen buttonsConfirmed


Related issues

Related to Tails - Feature #5660: wheezy: hide lock screen launcher Resolved
Related to Tails - Feature #9569: Research available protections against rogue USB devices Confirmed 06/13/2015
Related to Tails - Bug #12098: Spurious screensaver activation while synchronizing the system clock Rejected 12/29/2016
Related to Tails - Feature #5799: Deactivate screensaver until time is set Confirmed
Related to Tails - Feature #14556: Show a suspend to RAM button in the status menu Confirmed 08/30/2017
Duplicated by Tails - Feature #7045: Lock screen icon in taskbar if admin password entered at startup Duplicate 04/08/2014
Duplicated by Tails - Feature #7719: Add a screen locker Duplicate 08/01/2014

Associated revisions

Revision 814d2b02 (diff)
Added by Tails almost 3 years ago

Install and enable our custom shutdown-helper GNOME Shell extension (Closes: #8302, #5684 and #5878).

It adds a Lock Screen and Restart button to the GNOME user menu,
removes the press-Alt-to-turn-shutdown-button-into-Suspend
functionality, and makes Restart and Shutdown immediate, without
further user interaction.

It's based on laserb's gnome-shell-extension-suspend-button:
https://github.com/laserb/gnome-shell-extension-suspend-button

Revision e55f05d8 (diff)
Added by Tails almost 3 years ago

Install and enable our custom shutdown-helper GNOME Shell extension (Closes: #8302, #5684 and #5878).

It adds a Lock Screen and Restart button to the GNOME user menu,
removes the press-Alt-to-turn-shutdown-button-into-Suspend
functionality, and makes Restart and Shutdown immediate, without
further user interaction.

It's based on laserb's gnome-shell-extension-suspend-button:
https://github.com/laserb/gnome-shell-extension-suspend-button

Revision 19fb574d (diff)
Added by anonym 11 months ago

Make GNOME's default Lock Screen keyboard shortcut use our locker.

Refs: #5684

History

#1 Updated by Tails over 4 years ago

  • Priority changed from Normal to Elevated

#2 Updated by Tails over 4 years ago

  • Priority changed from Normal to Elevated

#3 Updated by Tails over 4 years ago

  • Priority changed from Normal to Elevated

#4 Updated by matsa almost 4 years ago

From the old forum thread, tested with Tails 0.21 :

The lockscreen function with gnome-screensaver is bypassable.
Here is how to reproduce:

  • Setup an administration password in the greeter
  • Install the package gnome-screensaver
  • Launch it with sudo -u amnesia gnome-screensaver
  • Lock your screen

Now, to unlock the screen without entering password:

  • Open a text-console with "Ctrl+Alt+F2"
  • Run the command killall -9 gnome-screensaver
  • Go back with "Ctrl+Alt+F7"

The screen is unlocked

#5 Updated by intrigeri almost 4 years ago

  • Easy set to No

matsa wrote:

The lockscreen function with gnome-screensaver is bypassable.

That's why there's the #5588 subtask..

#6 Updated by intrigeri over 3 years ago

  • Duplicated by Feature #7045: Lock screen icon in taskbar if admin password entered at startup added

#7 Updated by BitingBird over 3 years ago

  • Subject changed from screen locker to Screen locker

#8 Updated by intrigeri about 3 years ago

#9 Updated by mercedes508 about 3 years ago

When doing the following:

  • Enable persistence.
  • Add gnome-screensaver to
    /live/persistence/TailsData_unlocked/live-additional-software.conf
  • Restart Tails.
  • Set an administrative password.
  • Start the screensaver by running:

    gnome-screensaver-command --activate

The screen is not locked. No password will be asked to
disable the screensaver.

The administrative passsword should be asked to exit the
screensaver.

This can be achieved by issuing the following command:

gsettings set org.gnome.desktop.lockdown disable-lock-screen false

I recommend adding it in /etc/gdm3/PostLogin/Default when
an administrative password is set. It should have no effect
when gnome-screensaver is not installed.

#10 Updated by anonym almost 3 years ago

  • Target version set to Tails_2.0
  • Type of work changed from Code to Discuss

With shutdown-helper GNOME Shell extension (#8302) it is trivial to add the Lock Screen button when we're based on Debian Jessie. However, do we actually want to support screen locking?

Screen locking it's not a very strong defense for keeping the current session's data from someone that takes physical control of the computer running Tails. Still, it's better than nothing in a situation where you want to leave the session running among trusted people, but that you still do not want to have access to the session. Unfortunately users may get a false sense of security from this feature.

Next up, if we want to support it we probably want to avoid showing the Lock Screen button if no administrator password is set, since it may be confusing. That is quite doable by adding a dconf option (the original extension that shutdoen-helper is based on has code like that, so it can be borrowed from there) of wether to show it or not. And now we have hinted at another issue: by supporting screen locking we overload the administrator password Tails Greeter option with this functionality, which is non-obvious. The name may have to be changed, or the complete design of all this re-thought.

#11 Updated by micahflee almost 3 years ago

anonym wrote:

With shutdown-helper GNOME Shell extension (#8302) it is trivial to add the Lock Screen button when we're based on Debian Jessie. However, do we actually want to support screen locking?

Screen locking it's not a very strong defense for keeping the current session's data from someone that takes physical control of the computer running Tails. Still, it's better than nothing in a situation where you want to leave the session running among trusted people, but that you still do not want to have access to the session. Unfortunately users may get a false sense of security from this feature.

I think supporting this feature is very important. I've worked in multiple office situations where employees use Tails, and sometimes they need to step out of their office to use the bathroom, or join a brief meeting, etc., but don't want to shut down the computer because they're in the middle of work and will be back in a minute. It makes me very concerned that there's nothing protecting the active session when this happens. I don't like even walking out of a room to refill my coffee with my screen unlocked. I think a lock screen feature would go a long way to making Tails more secure.

It might make sense if there were some warning or message on the lock screen that informed users that locking the screen is not a strong defense against physical attackers, and that you should shut down the computer instead if you'll be gone for very long.

#12 Updated by BitingBird almost 3 years ago

The warning seems like a good compromise to me.

#13 Updated by intrigeri almost 3 years ago

It might make sense if there were some warning or message on the lock screen that informed users that [...]

Good idea, but not sure how well it would work in practice: in my experience, at least GNOME Shell blanks the screen (DPMS or something) immediately after it's been locked, so users would actually not see this warning before they come back and want to unlock the session. Of course, then they've seen it once, and can remember these shortcomings next time. Is that good enough?

#14 Updated by u almost 3 years ago

  • Related to Feature #8383: Research technical possibilities to implement a password prompt for screen locking added

#15 Updated by u almost 3 years ago

  • Related to Feature #8384: Investigate how other live/privacy distros do screen locking added

#16 Updated by u almost 3 years ago

  • Related to Feature #8385: Investigate if other distros are interested in our screen locking solution added

#17 Updated by u almost 3 years ago

During the contributor meeting a proposal was made:

instead of using the admin password (that is, really, user password + sudo), a second password would make sense. In order to set this password, we would prompt the user on the first usage of the screen lock feature to set a screen lock password.

This password could also be made persistent, for persistence users. See related tasks.

#18 Updated by intrigeri almost 3 years ago

  • Target version deleted (Tails_2.0)

#19 Updated by intrigeri almost 3 years ago

  • Related to deleted (Feature #8385: Investigate if other distros are interested in our screen locking solution)

#20 Updated by intrigeri almost 3 years ago

  • Related to deleted (Feature #8384: Investigate how other live/privacy distros do screen locking)

#21 Updated by intrigeri almost 3 years ago

  • Related to deleted (Feature #8383: Research technical possibilities to implement a password prompt for screen locking)

#22 Updated by sajolida almost 3 years ago

  • Type of work changed from Discuss to Research

#23 Updated by sajolida almost 3 years ago

  • Description updated (diff)
  • Blueprint set to https://tails.boum.org/blueprint/screen_locker

#24 Updated by sajolida over 2 years ago

  • Description updated (diff)

#25 Updated by intrigeri over 2 years ago

  • Related to Feature #9569: Research available protections against rogue USB devices added

#26 Updated by sajolida about 2 years ago

  • Description updated (diff)
  • Assignee set to sajolida
  • Target version set to 2017

#27 Updated by elypter about 2 years ago

besides trying to make circumvention as difficult as possible it should also indicate when the system has been unlocked and locked again.
this could be done by:
-showing the time the screen has been locked and how long
-an incerementing number that increases wen the screen is being locked
-a unique randomly generated visually distinctive and easy to remember image. like random-art.org or terragen. if there exist high quality alternatives it could look quite elegant as side effect.

#28 Updated by sajolida about 2 years ago

I'm not sure to understand your proposal. What concrete problem or attack are you trying to prevent with this?

#29 Updated by elypter about 2 years ago

*the victim goes away from his desktop
*the attacker goes to his pc and circumvents the lockscreen and then does his stuff
*then the attacker locks the screen again
*the victim comes back and doesnt notice anything indicating the attack

if every lockscreen looks different though the victim would be able to see that the system has been locked again and knows that he has been spied upon and his system could be compromized.

#30 Updated by elypter about 2 years ago

there could also be an indicator that shows if someone has tried to unlock the system by checking for keyboard, pointing device, camera, microphone, usb or accelerometer activity.

#31 Updated by sajolida about 2 years ago

If the attacker manages to circumvent the screenlocking, in most scenarios the security of Tails is already defeated. Noticing it might not change much. And the attacker might as well be able to circumvent the techniques that you are proposing. So I'm really not convinced it's worth it both for us in terms of technical work and for the user in terms of added complexity of the interface.

I'd rather work on making the user understand that leaving their computer unattended is very risky and should be with very much care.

Also, if I were an attacker with unlimited technical power, I would instead insert malicious devices in the computer ports (USB, firewire, etc.) with exploits to access memory. And that would be detected by none of your tricks.

#32 Updated by elypter about 2 years ago

sajolida wrote:

If the attacker manages to circumvent the screenlocking, in most scenarios the security of Tails is already defeated. And the attacker might as well be able to circumvent the techniques that you are proposing.

most of the time the threat model is not an attacker with unlimited technical power who wrote a tool specificly designed to circumvent the lock screen of a niche os. often its someone who looks over the shoulder of someone while hes typing the password or someone who tries to guess the password or someone who knows the password because the user trusts him.

Noticing it might not change much.

it might change a lot. he would know if he is in serious trouble or not. his life could depend on it.

I'd rather work on making the user understand that leaving their computer unattended is very risky and should be with very much care.

education and protection do not exclude each other.

Also, if I were an attacker with unlimited technical power, I would instead insert malicious devices in the computer ports (USB, firewire, etc.) with exploits to access memory. And that would be detected by none of your tricks.

plugging something in will trigger a notice on the lock screen. you could also disable plug and play during the lock.

#33 Updated by intrigeri almost 2 years ago

Testing reports on #9408#note-1 might be of some interest here.

#34 Updated by segfault over 1 year ago

I took the grml-lock.sh script mentioned in the blueprint and modified it to work with Tails 2.0. It asks for a password if there is none set and then it locks the screen. It is ugly and I have to parse the passwd output in order to find out if it was successful because I can't use chpasswd, which is the tool to change passwords in batch mode but requires root.
There is currently a bug which causes the screensaver to not lock the screen if the password was only just set. I reported this in the GNOME bugtracker: https://bugzilla.gnome.org/show_bug.cgi?id=761969
The current workaround is to wait for 2 seconds after setting the password.

During the contributor meeting a proposal was made:

instead of using the admin password (that is, really, user password + sudo), a second password would make sense. In order to set this password, we would prompt the user on the first usage of the screen lock feature to set a screen lock password.

This password could also be made persistent, for persistence users. See related tasks.

I currently don't set a second password and I don't make it persistent, because I see no benefit in either. I read the meeting's notes and still don't see the point. Why would the user want to set a second password instead of just using the one he set?
And what would be the benefit of making the password persistent instead of just asking the first time the screen is locked after boot (if no password was set on the greeter)? I only see a drawback: The user could forget the password he set the last time he used Tails and would not be able to unlock the screen.

Testing reports on #9408#note-1 might be of some interest here.

I tried to log in on tty and it requires the password.

#35 Updated by sajolida over 1 year ago

I tested your script and it works as intended. Good job!

I did some most tests security wise (as I didn't want us to set up an administration password this way), and no it's not possible to sudo after using your script; note that otherwise we would have had a big problem since years :)

Now I wonder about the integration on the desktop. I think we should aim at triggering your script in the same ways as the screen locker would be triggered in a normal GNOME: at least through Super+L and from an icon in the system menu. Debian has a padlock icon in the system menu, right? Maybe we did something to remove it.

Regarding the UI, I wonder whether a single dialog with two password fields would be better than two dialogs with a single password field. The combine two passwords is maybe more common, see this screenshot from GNOME Disks.

Maybe also we don't need the first dialog with no user interaction and fit this in a single dialog with the combined password fields.

Then I'd have some rephrasing to do on the user visible strings, but maybe before someone should do a more in depth technical review... or you should work on the integration.

Assigning to anonym to maybe have a very quick first look to validate the approach. Then maybe segfault should refine the integration and UI.

#36 Updated by segfault over 1 year ago

  • Target version changed from 2017 to Tails_2.4

Oh, I forgot to add myself to the watchers of this ticket. I only saw your comment on this just now, sajolida.

Thanks for testing it. I will set the target version to something sooner than 2017, so that anonym hopefully will have a quick look at this soon.

#37 Updated by segfault over 1 year ago

Now I wonder about the integration on the desktop. I think we should aim at triggering your script in the same ways as the screen locker would be triggered in a normal GNOME: at least through Super+L and from an icon in the system menu. Debian has a padlock icon in the system menu, right? Maybe we did something to remove it.

I found what we did to remove the padlock button, it's the disable-lock-screen = true line in this file:

config/chroot_local-includes/etc/dconf/db/local.d/00_Tails_defaults

You can disable this setting in your Tails session via this command:

gsettings set org.gnome.desktop.lockdown disable-lock-screen false

Triggering the script through Super+L is trivial, since we only have to change the keyboard shortcut. But I did not yet find a way to change the behaviour of the padlock button in the status menu (that's how the GNOME folks refer to this menu btw.)

Still looking forward to some short feedback if this is going the right direction. Then I would spend some more time on the remaining integration issues.

#38 Updated by segfault over 1 year ago

  • Description updated (diff)

#39 Updated by segfault over 1 year ago

  • Type of work changed from Research to Code

I rewrote the script in Python, created a small GUI in glade to realize the password setting in a single dialog and created a GNOME extension to add a screen lock button to the status menu which invokes the Tails Screen Locker.

I've put everything in this repository:
https://gitlab.com/segfault_/tails_screen_locker

Please test it :)

#40 Updated by segfault over 1 year ago

I append a screenshot of the dialog.

#41 Updated by anonym over 1 year ago

  • Assignee changed from anonym to segfault
  • QA Check changed from Ready for QA to Dev Needed

So far I've discovered these blockers:

  1. The GUI is not translatable.
  2. In the GNOME Session menu, let's place the new "Lock Screen" button between the Settings and Restart buttons , so the Restart/Shutdown buttons remain the rightmost ones and more easily accessible when in a hurry (i.e. for the emergency shutdown use case).
  3. Instead of introducing yet another GNOME Shell plugin, let's add the Lock Screen button to our existing Emergency Shutdown Helper plugin. Have a look at config/chroot_local-includes/usr/share/gnome-shell/extensions/shutdown-helper@tails.boum.org/extension.js. Some pattern matching and copy-pasting should do it. :)
  4. Check passwd's man page: "passwd will reject any password which is not suitably complex" => a too short password causes your password setter to silently fail. You need to handle this case, and I think the correct way is not to try to replicate the password complexity check in your tiny application, but to check stderr of passwd on error and see if the specific error string is there. For this reason you'll want to execute passwd with an English (or "C") locale too.

#42 Updated by anonym over 1 year ago

  • Status changed from Confirmed to In Progress

I should also add that it looks nice! :) Btw, I really appreciate that you provided scripts to help setting it up in a live session in absence of a Tails Git branch that I can build.

So, segfault, do you think you'll have time to fix these remaining issues in time for Tails 2.4 (especially since you have the Tails server GSoC now, and also (IIRC) said you'd have less time for Tails in general for the next couple weeks)? To be clear, for this to make it into Tails 2.4 we'd need to merge something with no serious issues (i.e. at least all of the above issues resolved, barring perhaps the plugin thing) before 2016-05-25.

#43 Updated by segfault over 1 year ago

So far I've discovered these blockers:

1. The GUI is not translatable.

I will look into this later.

2. In the GNOME Session menu, let's place the new "Lock Screen" button between the Settings and Restart buttons , so the Restart/Shutdown buttons remain the rightmost ones and more easily accessible when in a hurry (i.e. for the emergency shutdown use case).

Right, I thought the same and already did that :) The lock button only appears right if the GNOME Shell plugin was just installed. Just reload the GNOME Shell (Alt F2 -> 'r') and the lock button will be left from the restart and shutdown buttons.

3. Instead of introducing yet another GNOME Shell plugin, let's add the Lock Screen button to our existing Emergency Shutdown Helper plugin. Have a look at /extension.js. Some pattern matching and copy-pasting should do it. :)

I already looked at the shutdown-helper extension and copied code from it to the screen lock extension. I'm not sure why merging the plugins would be better than having them separated. The benefit of separate plugins is that we can more easily remove single functionality, if we ever need to do this.

4. Check passwd's man page: "passwd will reject any password which is not suitably complex" => a too short password causes your password setter to silently fail. You need to handle this case, and I think the correct way is not to try to replicate the password complexity check in your tiny application, but to check stderr of passwd on error and see if the specific error string is there. For this reason you'll want to execute passwd with an English (or "C") locale too.

Yes, I noticed this too. But I decided to not handle this case but instead allow users to use insecure passwords for their screen lock. After all, the screen lock is not very secure itself, so why should we force users to think up secure passwords and possibly tell them multiple times that their password is not good enough before they can lock their screen?
This check can be disabled by removing the "obscure" option to pam_unix.so in /etc/pam.d/common-password. I propose we do this. Sorry I forgot to mention this before.

#44 Updated by segfault over 1 year ago

I should also add that it looks nice! :) Btw, I really appreciate that you provided scripts to help setting it up in a live session in absence of a Tails Git branch that I can build.

:)

So, segfault, do you think you'll have time to fix these remaining issues in time for Tails 2.4 (especially since you have the Tails server GSoC now, and also (IIRC) said you'd have less time for Tails in general for the next couple weeks)? To be clear, for this to make it into Tails 2.4 we'd need to merge something with no serious issues (i.e. at least all of the above issues resolved, barring perhaps the plugin thing) before 2016-05-25.

If you think removing the secure password check is fine, I will prepare a commit. What do you think would be the right way to do this? A new script in chroot_local-hooks with sed -i 's/pam_unix.so obscure/pam_unix.so/' /etc/pam.d/common-password?

I'm not sure yet what has to be done to make it translatable. I will take a look at other Tails applications to figure this out. If this turns out to be the only remaining blocker, I will take the time to do this in time for 2.4.

#45 Updated by sajolida over 1 year ago

Also make sure that the doc is updated. I don't mind doing this after the branch is merged for code.

#46 Updated by segfault over 1 year ago

I noticed that the screen lock button reappears right from the shutdown and restart buttons after clicking it. I fixed this with the newest commit in https://gitlab.com/segfault_/tails_screen_locker.

#47 Updated by anonym over 1 year ago

  • Target version changed from Tails_2.4 to Tails_2.5

#48 Updated by intrigeri about 1 year ago

  • Target version changed from Tails_2.5 to Tails_2.6

#49 Updated by Dr_Whax about 1 year ago

  • Description updated (diff)
  • Target version changed from Tails_2.6 to 2017

#50 Updated by segfault about 1 year ago

  • Assignee changed from segfault to anonym
  • QA Check changed from Dev Needed to Ready for QA
  • Feature Branch set to segfault:feature/5684-screen-locker
The branch https://gitlab.com/segfault_/tails.git feature/5684-screen-locker is ready for QA. It should work like this:
  • Display a lock button in the GNOME status menu, between the settings button and the restart button
    On click it should:
  • Ask for a password, if no password was set before (there should be no password security check anymore)
  • Just lock the screen, if a password was set before

#51 Updated by anonym about 1 year ago

  • Assignee changed from anonym to segfault
  • QA Check changed from Ready for QA to Info Needed

Looks great, segfault!

If we get some user docs ready in time for 2.6, I'd (probably, see below) merge this. I would even consider merging this in time for 2.6~rc1 without docs if someone promises to deliver the docs before the final 2.6 release. I'm reassigning this ticket to you in hope that you manage something.

There is one potential UX issue: no locking will occur when GNOME blanks the screen after some extended period of no user activity. Try it by settings a lock screen password, and then run this as amnesia:

gsettings set org.gnome.desktop.session idle-delay 5

and wait for five seconds. I'm not sure whether this is a problem, and if it is, if it is a blocker. Any thoughts on this? I think I'd consider it a blocker to have this documented, if we keep this behavior.

#52 Updated by segfault about 1 year ago

  • Assignee changed from segfault to anonym
  • QA Check changed from Info Needed to Ready for QA

I pushed a commit which makes the screen lock when the screensaver is activated (if a password was already set previously).

#53 Updated by sajolida about 1 year ago

  • Target version changed from 2017 to Tails_2.6

Marking this for 2.6 until the status of this is clarified, see #5878#note-16.

#54 Updated by intrigeri about 1 year ago

  • Target version changed from Tails_2.6 to Tails_2.9.1

(Acting as the backup RM, which I am for 2 more days. I'm sorry this was not announced anywhere.)

2.6 has been frozen since September 1, so it's too late to get new features in. Sorry! Thus moving to the next major release.

#55 Updated by intrigeri about 1 year ago

anonym wrote:

If we get some user docs ready in time for 2.6, I'd (probably, see below) merge this. I would even consider merging this in time for 2.6~rc1 without docs if someone promises to deliver the docs before the final 2.6 release. I'm reassigning this ticket to you in hope that you manage something.

(FTR, this did not happen, hence the postponing.)

#56 Updated by anonym about 1 year ago

Your branch doesn't build, segfault. I've fixed the issues on the feature/5684-screen-locker in Tails main Git repo, which I recommend you fetch and look at.

I'm building an image now to test your recent changes.

#57 Updated by anonym about 1 year ago

  • Assignee changed from anonym to segfault
  • QA Check changed from Ready for QA to Dev Needed

Now I get two Lock Screen buttons in the GNOME "session" menu (or whatever it is called). I think this is a good reason to edit the existing Shutdown Helper GNOME extension instead of adding yet another GNOME extension. Less code to maintain, less complexity, less risk of conflicts between the two, which perhaps can explain this problem. Ok?

#58 Updated by intrigeri about 1 year ago

I think this is a good reason to edit the existing Shutdown Helper GNOME extension instead of adding yet another GNOME extension. Less code to maintain, less complexity, less risk of conflicts between the two, which perhaps can explain this problem. Ok?

+1

#59 Updated by intrigeri 12 months ago

FWIW the topic branch currently fails to build on Jenkins. Do we need to merge an update from segfault's branch?

#60 Updated by segfault 12 months ago

FWIW the topic branch currently fails to build on Jenkins. Do we need to merge an update from segfault's branch?

I will look into this soon

#61 Updated by segfault 12 months ago

The branch builds fine after merging devel.

I didn't test the image yet though, so I can't say anything about the two Lock Screen buttons anonym reported.

#62 Updated by segfault 12 months ago

I can't reproduce whatever caused anonym seeing two lock screen buttons.

#63 Updated by anonym 11 months ago

segfault wrote:

I can't reproduce whatever caused anonym seeing two lock screen buttons.

It's still an issue, see the attached image which shows three lock screen buttons. At least all of them work. :)

#64 Updated by anonym 11 months ago

anonym wrote:

segfault wrote:

I can't reproduce whatever caused anonym seeing two lock screen buttons.

It's still an issue, see the attached image which shows three lock screen buttons. At least all of them work. :)

During the same session I eventually ended up with four of them. I didn't do anything I can connect to this happening. Looking at your code and comparing it to the shutdown applet, I see some parts "missing", e.g. the stuff about this._menuOpenStateChangedId, but I fail to see why it should be related.

#65 Updated by anonym 11 months ago

I've pushed two commit to our repo's version of the branch:

d52d946 Enter a name into the Icedove account configuration.
19fb574 Make GNOME's default Lock Screen keyboard shortcut use our locker.

Please review'n'merge, segfault! :)

#66 Updated by anonym 11 months ago

All code looks good, but please move tails_screen_locker from:

/usr/lib/python3.4/dist-packages/

to
/usr/lib/python3/dist-packages/

The former is not used, and let's try to not (pretend to) depend on specific python versions. An other idea is to move it into Tails' pythonlib Git submodule in case you see any advantage in it.

So what remain before I can merge this branch is what I just said above + the "multiple screen locker icons" issue + the user docs (#10970).

#67 Updated by segfault 11 months ago

I've pushed two commit to our repo's version of the branch:

I can't find your commits. Did you forget to push? The last commits are from September: https://git-tails.immerda.ch/tails/log/?h=feature/5684-screen-locker

#68 Updated by segfault 11 months ago

  • Assignee changed from segfault to anonym
  • QA Check changed from Dev Needed to Info Needed

#69 Updated by anonym 11 months ago

  • Assignee changed from anonym to segfault
  • QA Check changed from Info Needed to Dev Needed

(Force-)Pushed now. I also pushed two more commits:

850afd7 Use the LIVE_USER variable instead of 'amnesia'.
f70dae8 Make live-build hook into live-config hook.

These are in fact old commits (before this force-push) that I asked you to cherry-pick/merge into your branch, which you did not. Please try not to lose such feedback in the future -- it's part of the review process!

#70 Updated by segfault 11 months ago

I also pushed two more commits:

850afd7 Use the LIVE_USER variable instead of 'amnesia'.
f70dae8 Make live-build hook into live-config hook.

These are in fact old commits (before this force-push) that I asked you to cherry-pick/merge into your branch, which you did not. Please try not to lose such feedback in the future -- it's part of the review process!

I did merge these commits into my branch, but in my branch they have the commit ids 0ceea16b and 5cae9c30:
https://gitlab.com/segfault_/tails/commit/0ceea16bbc945d4bc3223a130da82f51d96e2405
https://gitlab.com/segfault_/tails/commit/5cae9c30855a6178616b21f31ee17ffc4edf464e

I don't know why they have different id's than yours.

#71 Updated by anonym 10 months ago

  • Target version changed from Tails_2.9.1 to Tails 2.10

#72 Updated by intrigeri 10 months ago

  • Related to Bug #12098: Spurious screensaver activation while synchronizing the system clock added

#73 Updated by intrigeri 10 months ago

If #12098 is fixed before the screen locker is completed, then we might want to re-enable the idle timeout whenever the time is not being synchronized.

#74 Updated by intrigeri 9 months ago

  • Related to Feature #5799: Deactivate screensaver until time is set added

#75 Updated by anonym 9 months ago

  • Target version changed from Tails 2.10 to Tails_2.11

#76 Updated by intrigeri 8 months ago

  • Target version changed from Tails_2.11 to Tails_2.12

#77 Updated by intrigeri 6 months ago

  • Target version changed from Tails_2.12 to 2017

segfault, next time you'll work on this, please:

  1. document what's left to be done (e.g. in case someone wants to help), preferably as subtasks; lack of clarity wrt. the status of this endeavour seems to be a problem on the end-user doc side, and I'd like to avoid us being in a catch-22 where the person who is responsible for the last thing to do is waiting for someone else (undefined) to do something else (undefined) first;
  2. set a target version you find realistic (or none at all, it's fine too); meanwhile I'm setting it back to the 2017 one (as decided at the summit), which conveys our goals better than postponing to next release multiple times in a row.

Thanks in advance!

Also, with my 3.0 RM hat on: if you want to see this in Tails 3.0, then something well tested, that takes into account all comments and important use cases, needs to be ready by May 15. But this can very well wait until the latest 2017 major release (3.2, 2017-10-03) or be postponed to next year if you prefer.

#78 Updated by segfault 6 months ago

  • Target version changed from 2017 to Tails_3.2

intrigeri wrote:

segfault, next time you'll work on this, please:

  1. document what's left to be done (e.g. in case someone wants to help), preferably as subtasks; lack of clarity wrt. the status of this endeavour seems to be a problem on the end-user doc side, and I'd like to avoid us being in a catch-22 where the person who is responsible for the last thing to do is waiting for someone else (undefined) to do something else (undefined) first;

I think the only remaining blocker is that sometimes multiple lock screen buttons appear in the GNOME status menu. I just created the subtask #12449 for this.

  1. set a target version you find realistic (or none at all, it's fine too); meanwhile I'm setting it back to the 2017 one (as decided at the summit), which conveys our goals better than postponing to next release multiple times in a row.

[...]
Also, with my 3.0 RM hat on: if you want to see this in Tails 3.0, then something well tested, that takes into account all comments and important use cases, needs to be ready by May 15. But this can very well wait until the latest 2017 major release (3.2, 2017-10-03) or be postponed to next year if you prefer.

I think 3.2 is realistic. I have little free time until summer. I don't think I will be able to spend time on this in time for 3.0. The little time I can spend on Tails currently I prefer to spend on getting a Tails Server beta release done.

#79 Updated by intrigeri 6 months ago

I think 3.2 is realistic. I have little free time until summer. I don't think I will be able to spend time on this in time for 3.0. The little time I can spend on Tails currently I prefer to spend on getting a Tails Server beta release done.

Sounds very reasonable. Thanks for the update!

#80 Updated by segfault about 2 months ago

  • Related to Feature #14556: Show a suspend to RAM button in the status menu added

#81 Updated by segfault 22 days ago

  • Target version changed from Tails_3.2 to Tails_3.4

Also available in: Atom PDF