There's now a generic "note" credential type which lets you store a big chunk of secret text.

It seems increasingly clear that T6860 was a really bad idea. New pathway forward here is completely straightforward:

Implement a new subclass of PassphraseCredentialType which works like PassphraseCredentialTypePassword but stores a large block of text (like a configuration file, or a secret will, or the eldritch words of command which must not fall on mortal ears). This could be called "Note" or "Block" or "Blob" or something similar.

I plan to add a "note" or "text" type to Passphrase to handle this, but there isn't a good approach now.

I think this was tricky because we don't know what kind of credential to add (the user could put either an HTTP or SSH URI into the box) and the "add credential" dialog workflow needs (or needed?) a type. There's no reason we can't ask the user for a credential type.

A related request is to enable it, but require passphrases.

I'm seeing this on the current version in my environment also. As oyvindselbek mentioned, everything seems to be working (updates are happening) except for the cleanup of the temp files.

Y'all are also welcome to just stack all finds in one task description, and we'll just attach multiple commits. Whatevers easier.

Because you did, :P

(why do I feel like I just said GO at an easter egg hunt)

Imma presume this specific task is to fix Passphrase. Developers specifically needing to check permissions and setting disabled on the button if access won't be granted. I understand it may also be incorrect in other applications, but we have to one-off fix them, it's not a global thing.

Yea, its in multiple applications

swisspol: what we do, which could be a workaround for you, is to store the private key in secret, and upload the certificate via /file. Files have access control as well, so you can limit access to the certificate. Then the description in passkey is something like 'Download the certificate at Fxxxx'.

• Passphrase now supports title substring queries.
• Global search now supports full text queries (title + description + transactions + etc).
  • Use bin/search index --type CDTL to index existing credentials.

Closed by commit rPedc4c219caa9.

I'm still getting this problem with the latest pull :(
A few hundred thousand copies of my key every week :(

Closed by commit rPc07425c534e0.

I'm taking care of this issue.

@lpriestley: Let me know when you get here and I can walk you through it.

I'm going to merge this into T4721, which has more discussion. @hach-que's summary is essentially correct.

Phabricator needs the ability to decrypt credentials in background processes and in a non-interactive manner. Thus any key to decrypt a credential would need to be stored at the same level as the Passphrase credential itself, defeating the point of encryption (you can't store the decryption keys as a file outside MySQL because that won't scale for HA).

Thats awesome, thanks guys! I had a cron job deleting these file hourly as well. Please let us know if the issue is indeed fixed with Evan's commit.

Cool. A possible first-degree approximation is checking if the files contain private key material -- I'm not sure if we ever did that. If they're empty, that's a smoking gun for this being the issue.

I'm still working through my backlog after a long vacation to Iceland, but I'll nuke the cron job I had cleaning out the test directory and see if we still see the behavior.

Closed by commit rPHU8695cdb1270b.

@wotte / @wassere, if you still see this locally, can you check if that fixed your issue?

Cool and fast! Thanks!

Oh, except that when you call a method on null we don't actually get an exception because PHP is sort of derp and everything just dies abruptly. This script reproduces the issue, at least potentially:

Although I would expect the temporary file to be destroyed even if the exception is raised. This is still a bug in any case, since we shouldn't write the file in the first place.

That's extremely helpful, thanks! I'll get that fixed up.

It could be related:

Closed by commit rP26f283fe21a5.

I don't think denying access based on MFA or requiring it over Conduit would be very useful because we currently enforce MFA and it would remove the primary use; which is build agents retrieving credentials.

This is mostly OK from a security perspective, but we do ship users through a multi-factor auth check before revealing a credential if MFA is configured.