We’re on Octopus Deploy 2018.9.0–a bit outdated, yes, so my apologies if this is fixed. If this is fixed, could you kindly tell me what version contains the fix for this issue?
Here’s the issue. We have deployment processes that are used as “templates” for creating other deployment processes for customized versions of our application. (Nevermind the why–it’s just the way it is for lack of any (known) better way of accomplishing what we need. 
) Anyway, for better or worse, we have some project-level variables on the template which, for some reason, are not marked as IsSensitive to begin with (and that’s our mistake).
During the “seeding” process, which clones the template and prepares it for application deployments, these variables have their IsSensitive property updated to true and at the same time have their contents updated to a new, “sensitive” value. When you change the IsSensitive property value and the variable’s Value property in the same transaction, Octopus Deploy will “leak” the variable’s new value contents into the Audit log as plaintext.
I submit that this behavior should be changed. If upon receiving a request to update a variable set, one or more of its variables have had their IsSensitive property updated from false => true, then the contents of the variable’s new value ought to be obscured in the Audit log. (Naturally, going from true => false doesn’t matter, and the contents can be displayed in the Audit log.)
BTW, I apologize, I’ll be away for the next 3 weeks. I’ll attempt to reply via email while I’m gone, but I won’t have access to my company’s Octopus Deploy server during this time.
Hi @fourpastmidnight
Thanks for getting in touch and pointing this one out!
I’ve tested against the latest LTS and can confirm that this is no longer the case, however I can’t find a specific change that would have fixed it (at least not explicitly). Below is the audit log that I’m seeing (string>senstive and NotYet>Encryptedvalue):
Established with:
Session cookie
User agent:
Portal
Category:
Document modified
{
"Id": "variableset-Projects-61",
"OwnerId": "Projects-61",
"Version": 12,
"Variables": [
{
"Id": "e0865287-2ef2-8e1e-aee7-ab12ba2d6ddc",
"Name": "isPrivate",
"Description": null,
"Type": "~String~Sensitive",
"Value": "~NotYet~udAhnL1xDZvDeXO1v/hl2+L9TTI=|QfnN4fA5Jka0beyZ"
}
],
"SpaceId": "Spaces-1",
"RelatedDocumentIds": []
}
A quick note here, my testing involved creating a new project level variable, then once that has been saved changing both the type (to sensitive) and variable value in the same save process. Let me know if this doesn’t match what you are doing and I’d be happy to retest.
Regards,
Alex
Alex,
Could you please try modifying an existing project level variable in the manner specified instead? I’m thinking, if it’s not fixed, that this only occurs when updating an existing variable.
Thanks.
Hi @fourpastmidnight,
I’ve confirmed that we don’t leak information on existing variables either, note the version number here:
Let me know if there is anything else you would like me to test.
Regards,
Alex
But, you see the new value of the variable in the audit trail! (Did I misunderstand and I’m only seeing the encrypted version of the new value?)
Hi @fourpastmidnight
That’s right, the crossed out value is the old, unencrypted, value. The new value you are seeing is a hash of the new one (but not the value itself).
Regards
Alex
Alex:
Oh, whew! Ok, I’m sorry about that, I misunderstood what I was seeing. Thanks so much for your help!!
No problems, happy that we could sort that one out!
Regards
Alex
