Project

General

Profile

Feature #6270

Publish our Jenkins read-only on the web

Added by intrigeri over 6 years ago. Updated 2 months ago.

Status:
Confirmed
Priority:
Low
Assignee:
-
Category:
Continuous Integration
Target version:
-
Start date:
09/10/2013
Due date:
% Done:

0%

Feature Branch:
Type of work:
Sysadmin
Blueprint:
Starter:
Yes
Affected tool:

Description

It would be great if non-core developers could see how things go on the Jenkins side, especially to read failed build logs.

Ubuntu and Debian have such a setup working.

It seems that we could simply:

  1. Replace our current simple HTTP authentication with Jenkins' own authentication system.
  2. Install Jenkins Read-only configurations plugin

Related issues

Blocked by Tails - Bug #10068: Upgrade to Jenkins 2.x, using upstream packages Resolved 01/08/2018

History

#1 Updated by intrigeri over 6 years ago

  • Starter changed from No to Yes

Flagging as "Easy" for now, since the initial research does not require a special setup nor any privileges.

#2 Updated by bertagaz over 4 years ago

So, I've talked a bot with weasel about that too. At Torproject, they're using the plain Jenkins authentication abilities and the matrix based ACL to secure access to their instance access.

Maybe if we choose to use the upstream LTS Debian package as they do, which has better security support than the one from Debian (well, because it's upgraded more often at least), we could consider doing the same and rely on Jenkins rather than researching something than no one else seems to do.

#3 Updated by intrigeri over 4 years ago

At Torproject, they're using the plain Jenkins authentication abilities and the matrix based ACL to secure access to their instance access.

https://wiki.jenkins-ci.org/display/JENKINS/Matrix-based+security or https://wiki.jenkins-ci.org/display/JENKINS/Matrix%20Authorization%20Strategy%20Plugin ?

Maybe if we choose to use the upstream LTS Debian package as they do, which has better security support than the one from Debian (well, because it's upgraded more often at least), we could consider doing the same and rely on Jenkins rather than researching something than no one else seems to do.

I've quickly looked at this again and I agree.

#5 Updated by intrigeri over 4 years ago

  • Related to Bug #10068: Upgrade to Jenkins 2.x, using upstream packages added

#7 Updated by intrigeri 7 months ago

  • Related to deleted (Bug #10068: Upgrade to Jenkins 2.x, using upstream packages)

#8 Updated by intrigeri 7 months ago

  • Blocked by Bug #10068: Upgrade to Jenkins 2.x, using upstream packages added

#9 Updated by intrigeri 3 months ago

Note that the test job runs logs contain passwords that we probably don't want to expose publicly.

#10 Updated by anonym 2 months ago

intrigeri wrote:

Note that the test job runs logs contain passwords that we probably don't want to expose publicly.

Indeed. I see a couple of ways to solve this:

  1. For simplicity, let's assume that the password leaks all occur when @screen.type() them. Then I could add an option to suppress the logging, e.g. @screen.type("trustno1", log: false), and then we'll just have to be careful and do that for each occurrence when we type (secret) passwords. And since the assumption probably doesn't hold we'd have to look for other ways the passwords leaks and add support for log: false to them too (e.g. probably Dogtail, which any way could use some work to reduce its excessive logging).
  2. On Jenkins, we could post-process the logs by reading all the .json files in features/config, extract all their password fields, and for each $PASSWORD just s/$PASSWORD/XXX_CENSORED_XXX/g on the debug.log.

Of course, passwords could still leak, e.g. if there is a GUI focus issue the password could end up being typed into the wrong place, like a normal text area that is visible in a failure screenshot/video. I think that's something we could live with, at worst an attacker can make Jenkins' tests fail. If that turns into a recurring headache we can always just revert.

#11 Updated by anonym 2 months ago

Actually, at least in the email tests it's not enough to hide the password: by learning the email address an attacker can fill the inbox resulting in test failure. So we could @screen.type(email_address, log: false) to fix the logs, but the email address would still appear in any failure screenshot/video where it was typed since its not a password field that hides the characters.

I think I still would like to try this and not get too discouraged by these theoretical attacks. Thoughts?

#12 Updated by intrigeri 2 months ago

Actually, at least in the email tests it's not enough to hide the password: by learning the email address an attacker can fill the inbox resulting in test failure. So we could @screen.type(email_address, log: false) to fix the logs, but the email address would still appear in any failure screenshot/video where it was typed since its not a password field that hides the characters.

I think I still would like to try this and not get too discouraged by these theoretical attacks. Thoughts?

I agree the disclosure of the test email address is not, in itself, a blocker.

Making it possible to not log passwords seems worthwhile to me regardless of whether we end up publishing our Jenkins read-only (that's very unclear to me at the moment: we don't know if we'll still be using Jenkins in 2-3 years, and there are probably a bunch of other, bigger blockers than password logging):

  • Our track record wrt. not publishing logs is not good. There might be other places where these passwords are leaked.
  • It would also be useful (or possibly, needed) if we migrate to another CI system.
  • More generally, it just makes sense to me that CI artifacts should be things we can publish and share. I think that most of the password leaks problems we had so far happened because someone (sometimes myself) was implicitly acting based on this assumption. Let's make this assumption correct :)

So I'm definitely in favor of capturing this idea in a dedicated ticket (blocking this one), where we can discuss/prioritize this further. I doubt it's close to the top of the list of the most useful/important test suite work we have on our plate though.

Also available in: Atom PDF