Signing Wikis or Tickets

Did you intend to open this request against the AccountManagerPlugin?

Could be, I am not completely aware of the internal structure of the TRAC environment, where would be the best place to work with certs while achieving maximum security. I think that should be selected by someone that has a deep knowledge about that.

Hm, nice idea, can imagine such a functionality. Moreover it could be a good fit to existing corporate policies backed by public key infrastructure.

It reminds me to put more effort into the crypto-extension to TracAnnouncer. But at the same time it shows that the approach overthere has been to foccused on email content, while it occurs to me right now, that we could make use of a generalized crypto-infrastructure. This could be used for both, the TracAnnouncer extension as well as signed content as proposed here. All in all a nice fit for my TrustedTrac proposal.

As far as I can see AccountManagerPlugin is mentioned here as a possible dock for the crypto-foundation, because per-user certificate-/key-management certainly would be needed as a prerequisite.

There are probably many ways of how is to be done, maybe the thing to be considered:

• trac probably might need some 'root' certificate to validate the signatures
• if there are pre-installed certs then server might undergo all the security issues

Practically any content could be signed, or with some additional macros owner of the content may require somebody to sign it such as [[ToBeSigned(account names....)]] and the content becomes valid only when all of them have signed them. And each user would receive an email, a request to sign the content. User may also decline signing if he does not agree with the content, which should also be noted.

So below the content I think some new 'lines would appear' such as:

User <.....> has signed the content.

User <.....> is pending to sign the content.

User <.....> has declined to sign the content.

If content changed afterwards, then probably an additional note would appear:

User <.....> has signed the content of version XXX, and is not up to date with the latest content.

in which case user may re-assign the latest content, or again, decline, etc...

Before somebody would change the signed content there should be a warning message. However above I already mentioned the possibility to lock the pages when signed, such as: [[SignNLock(users,...)]] to keep the content permanently there as long it is signed. This is good for a kind of negotiations between parties of what to do and what not to do...

Good news: That's gonna happen now.

I've actually started development few days ago, so I'm happily assigning this to the upcoming plugin.

Great!

See #10080 for the corresponding development ticket to create the required foundation for the cryptographically-backed functions requested here.

While testing bare implementation without locking by signature I wonder, if the unlocking should really require deleting the signature.

Did you propose this for a certain reason? I tend to dislike this particular suggestion, because the signature is always valid for a given, unaltered resource version only, not more, not less. It might be preferred to keep older signatures for historic version, i.e. for ticket comments and wiki page revisions, that one could treat like officially released texts, and even hide other non-signed content from the public (anonymous users).

So what to you think? Would it be acceptable for you to treat signatures as locks by just raising the bar for next edit to same level as signature deletion permission, but without actually deleting the signature when granting edit access? Does this make sense to you at all?

Just imagining how this might be used in my environment, I favor the idea of signing versions of a resource and having the signature be permanent. If the resource is unlocked and edited, then a new signature must be applied to the new version. Perhaps you could eventually allow a signer to revoke their signature for a version of a resource, but retain the history of the signing / revocation actions.

Replying to rjollos:

... If the resource is unlocked and edited, then a new signature must be applied to the new version.

Sure, this is what I'm already testing locally here.

Perhaps you could eventually allow a signer to revoke their signature for a version of a resource, but retain the history of the signing / revocation actions.

Hm, good catch. Signatures are ultimately binding right now.

But you're right that revocation is allowed in the cryptographic world, at least for keys signatures. I'll think it through how to do such a revocation in the least intrusive yet most effective way. I guess, it'll require another db entry in the 'crypto' table, maybe even another column to mark the revocation unambiguously.

Signature expiration and revocation are both implemented as of today.

Both must be explicitly activated by an admin user per Trac environment, so non-expiring, non-revocable signatures are still the default.

Thank you for your valuable feedback, that went into yet another redesign of the database schema. It looks much cleaner now and makes me more confident to meet expectations this time.

Resource locking is among the last few things left to be done now. The major questions are:

• Could we re-use existing 'read-only' for locking or do you rather imagine a separate wiki page state? There are several ways to achieve page tagging as r/o and for unlocking, depending on this.
• Loosely coupled to the previous one, I would expect users without 'CRYPTO_ADMIN', 'CRYPTO_DELETE' (second highest permission level as of today) and 'TRAC_ADMIN' to be unable to lock as well as to edit locked pages. Note, that this is intentionally decoupled from wiki permissions 'WIKI_EDIT' and 'WIKI_ADMIN'. We must have this privilege separation, or not?
• While it could be arranged to allow page locking by someone with lower privileges than required for unlocking, this seem too complicated, and I can't think of a use case for such an elaborated permission hierarchy.

I could use a few more of your opinions. Anything else to care for?

I've just written some cheap code to implement the following behavior:

• if wiki page has been signed, require 'CRYPTO_SIGN' permission to edit or delete
• otherwise proceed as normal (assert 'WIKI_MODIFY'/'WIKI_DELETE' or higher, or 'WIKI_ADMIN' on readonly state)

This is the least intrusive way to allow page locking, provided 'CRYPTO_SIGN' is configured as an elevated permission. It is granted to authenticated users by default, so you need to changed that for page locking to be effective for logged-in users with 'WIKI_MODIFY' or 'WIKI_ADMIN' permission.

The decisions you've made sound good to me, and I expect they'll provide a good starting point. While I'm not sure that locking and unlocking privileges need to be decoupled, it would be nice to provide a way for a user to request that a page be locked, and have them go into a queue on an admin page. That is a refinement though that I'm sure we can live without for the first version of the plugin.

Replying to rjollos:

The decisions you've made sound good to me, and I expect they'll provide a good starting point.

I hope so.

While I'm not sure that locking and unlocking privileges need to be decoupled,

Me too. I see an overall concept of giving power to do to whom that can undo it too, with exception of initial ticket values, that get read-only for the unprivileged reporter after commit.

it would be nice to provide a way for a user to request that a page be locked, and have them go into a queue on an admin page. That is a refinement though that I'm sure we can live without for the first version of the plugin.

Hm, this seem like a rather specific demand. This asking for admin action status is sort of an edit queue with waiting-for-moderation content, like pro-active SPAM filtering.?

But I miss the value for a dedicated workflow in this plugin, because I think it could be done right-away with TagsPlugin by simply tagging such pages with a suitable tag like 'sign-lock-proposed' combined with a [[ListTagged('sign-lock-proposed')]] on an administrative ToDo page.

Btw, since 'CRYPTO_SIGN' is granted to authenticated user group by default, you'd need to take actions anyway. You can arrange for 'CRYPTO_SIGN' assignment combined with 'WIKI_ADMIN' to get what most people may see as "coupled" permission schema.

But it's entirely up to you, if and how high you want to rate signature-driven locking over regular access restrictions. This was just an example of mine to tell about possible independence from Trac core permissions for the wiki.

Another idea that occurred to me while coding was, that someone might like to set the latest signed version as default page rather than the latest version. So I'll provide the option wiki_signed_pages_focus to switch such redirection globally for each environment (off by default).

Replying to hasienda:

Hm, this seem like a rather specific demand. This asking for admin action status is sort of an edit queue with waiting-for-moderation content, like pro-active SPAM filtering.?

Yes, I agree it is too specific for your plugin. I think the feature could be best implemented through a wiki document workflow. The TracGenericWorkflowPlugin may support a wiki document workflow, but I haven't looked closely yet. Using TagsPlugin sounds like a good general solution as well, but for the specific case I have in mind, a workflow will be better, I think (more on that later).

Replying to hasienda:

Another idea that occurred to me while coding was, that someone might like to set the latest signed version as default page rather than the latest version. So I'll provide the option wiki_signed_pages_focus to switch such redirection globally for each environment (off by default).

The wiki_signed_pages_focus option would be very valuable to me. As I've followed your work on this plugin, I've realized that you are implementing a large part of the Document Management plugin that I had envisioned developing for my company. We have a 1-person document control department that handles signatures and publishing the latest versions of documents. I've wanted to replace this role and manage all of our documents on the wiki. Cryptographic signing is certainly a requirement for doing that, as is making the latest released versions of documents available and easily identifiable. There are also a bunch of other features I had envisioned that you may be interested in, so I'll make sure to share those once I have all of my thoughts together. I'm looking forward to testing out your plugin!

t:ticket:10125#comment:15 made me look at my work differently again.

Because all that seems reasonable and likely best-practice, I'll rework the whole existing patch stack to respect a stricter policy for API layers according to osimons guidance.

(In [11813]) CryptoPlugin: Implement some functionality now, starting with OpenPGP, refs #10030 and #10080.