Home → Questions →

Prevent plaintext log of secure variables in live build log stream

• Edit

Jeroen Heijmans

27 Mar, 2019 09:15 PM

EDIT: Title was updated as it later turned out this is not about being logged in or not, but about the logs being seen in the live stream or not.

In another thread I got excellent help to get secure variables working in my public open source repository.

To double check if the AppVeyor logs properly hide the secrets, I wrote an xUnit test that effectively does this:

[Fact]
public void Debug_environment_variable_key()
{
    // To debug AppVeyor's behavior with cleaning the logs of secrets:
    Assert.Equal("dummy1", SearchTestFixture.apiKey);
}

The apiKey comes from a secured variable in my appveyor.yml file. When I view the build log in an incognito browser window (so not logged in), I correctly see ****** instead of the actual decrypted value.

However, when logged in, the logs do show the actual values. I don't want this, as folks might be looking over my shoulder, or I might be demo-ing my setup in a presentation.

See attached picture for a test run, showing the log as I see it when logged in.

Is there any way to always prevent decrypted values from showing up in logs, even when viewing those logs logged in as a project admin?

• appveyor-problem.png 8.84 KB

1. 1 Posted by Ilya Finkelshte... on 27 Mar, 2019 11:28 PM

   

   This is unrelated to the fact if you are logged in or not.

   Secure variable is decoded to clear text during the build, otherwise code like your could not use it. If secure variable is leaked, it will be displayed in clear text in live build console. But as long respective part of build log saved, it is replaced with *****. Searching for leaked secure variable values in live console stream will introduce performance hit we cannot afford. So compromise solution is to replace them with ***** when saving logs. And yes, it is imperative that secure variable values should not be displayed.

   • Edit

2. 2 Posted by Jeroen Heijmans on 28 Mar, 2019 07:48 AM

   

   Wait a second, if I understand you correctly, even anonymous users watching a live build stream can see secure variable values in the log if my code would ever somehow output them?

   Why then are the values masked in saved logs? That only obscures the attack surface slightly, giving users that don't know this a false sense of security. That's even worse than just never masking the values, in my opinion.

   Either way, of course many thanks again for a prompt response!

   • Edit

3. Ilya Finkelshteyn closed this discussion on 28 Mar, 2019 04:30 PM.

4. Jeroen Heijmans re-opened this discussion on 28 Mar, 2019 07:41 PM

5. 3 Posted by Jeroen Heijmans on 28 Mar, 2019 07:41 PM

   

   Before closing, could you confirm and/or answer my questions in my last post? Is there no way to prevent anonymous users from seeing unmasked "secure" variables in the live build stream, if they'd ever be shown by my build?

   • Edit

6. 4 Posted by Ilya Finkelshte... on 28 Mar, 2019 08:20 PM

   

   I just do not have too much to add... Environment variables must be in a clear text in memory, otherwise they are unusable. And no one can stop people from shooting in own foot by printing them to the console. If people do not print secure variables (which we cannot control), the only way they can be displayed is some wrongly written application exception leaking them. This is not something which can be caught by watching live stream. And yes, secure variables are not available in pull requests. Parsing live console output is not feasible from the performance point of view. This is usual compromise between security and usability.

   • Edit

7. 5 Posted by Jeroen Heijmans on 30 Mar, 2019 04:08 PM

   

   Okay, thank you for the confirmation. I felt the conclusion was so crazy, that I must've misunderstood.

   It's a shame that apparently performance is a blocker, and I would urge you to stop masking the values in persisted logs as they give a false sense of security.

   If you won't consider that, and performance remains a blocker to remove it from the live stream, then I guess the ticket can be closed (assuming it remains visible for others to spot the issue?).

   Either way, thanks once more for a prompt reply!

   • Edit

8. 6 Posted by Ilya Finkelshte... on 31 Mar, 2019 09:53 PM

   

   You are welcome! Yes, it stays visible as long as it is a public discussion.

   • Edit

9. Ilya Finkelshteyn closed this discussion on 31 Mar, 2019 09:53 PM.