...possibly, but not conclusively, a result of an SSH version upgrade...

I've marked D20905 as resolving this. This isn't really "resolved" completely, but T13454 has a better description of what the problems are and why they're difficult. Our behavior is, at least, substantially better than it was before.

I have been trying to see about another way to do this until this is added (if it is I should say). We are finally getting ready to move to Phabricator, and I was hoping there was at least a shortcode or something I can use. Currently what I was trying to do was paste the query URL for a particular project's Passphrase credentials. What we were going to try was getting the query for whichever project's passwords, copying it, and adding it to the Project as a custom link.

Thank you, that was a very quick resolution, I just had the time to refresh the page !

GHC would also find support for importing keys from Github useful; we are currently working on rolling out a Diffusion-hosted staging area for use with Harbormaster but the need for contributors to submit their key to yet another Phab feels like unnecessary friction.

In T4721#140545, @joshuaspence wrote:

In T4721#53743, @epriestley wrote:

And we should possibly consider splitting the permissions more granularly:

• View
• Show Secret
• Edit

+1

You can talk to Passphrase over Conduit; you need to give credentials access by clicking the "Allow Conduit Access" action.

This is conceptually reasonable, but likely years away. We ship no native code right now. Although there are many Phabricator applications which could take advantage of an optional OS client (for example, to make it easier to upload screenshots or access files) the pathway from where we are now to building one is a very long one, and none of these use cases are near the top of our priority list.

I am waiting tag(s) field for credentials too.

I'm going to merge this into T10748. It should technically be fixed by D15829 on its own, but will be fixed even harder once we cut over to the changes in T10748.

Should be fixed in HEAD of master. Thanks for the report!

T10772

You shouldn't be getting an exception.

It's the git master from yesterday, wasn't sure if it's a bug or an installation/config error.

What revision is your install running on? If it's recent then this might be a legitimate bug and should be reported.

I tried to add a new credential.

Sounds good, let us know if you run into anything else.

Latest version seems to have fixed this. Sorry for the noise, and thanks for building such an awesome software.

For completeness, T10651 is the earlier report.

(fantastic bug reporting, otherwise)

I think that stuff isn't linking because someone is pushing their own branches to the upstream staging repository, making the commits ambiguous. That is, e3f89279f912 is ambiguous as either rPe3f89279f912 or rSTAGINGe3f89279f912.

rPe3f89279f912 should have resolved this, I believe.

Doh. Give me a minute, testing with 3493d9d5138e0a630624bced548090163ce9be8a now.

Your install is out of date.

Works now; thanks!

Whoops, thanks. This got rebased across 200 years of changes and I didn't re-test creating a credential. D15512 should fix it.

d'oh - thanks - I feel like at one point that wasn't yet available and must've just assumed it still wasn't.

You should be able to do "Visible To: Members of X" already (or use Spaces, even). Tags wouldn't affect visibility.

Would having tags on passphrases mean that they would be usable by members of the group? I just did a check as I thought I had created a task about this previously but does not appear to be the case (maybe I was keeping it in a create form and never submitted).

EDIT: I removed my prior replies to clean up the thread and avoid anyone in the future mistaking what I wrote as anything but a simple misunderstanding.

(I did half a diff on tags-on-credentials yesterday but Passphrase uses a couple of unique elements (like a "password" control) that don't currently have field support in EditEngine, so conversion wasn't entirely straightfoward.)

There's some usual magic on this dialog to try to make sure the "you looked at the secret" transaction is shown to you when you close the dialog to make it more obvious that your view was logged.

In T4721#53743, @epriestley wrote:

And we should possibly consider splitting the permissions more granularly:

• View
• Show Secret
• Edit

This is 1-2 hours of work and can be slipped in somewhere if approved.

subscribbable

Hmm, nevermind me.

I can't reproduce this: