Modify

Opened 2 years ago

Last modified 21 months ago

#10030 new enhancement

Signing Wikis or Tickets

Reported by: uros@… Owned by: hasienda
Priority: normal Component: CryptoPlugin
Severity: normal Keywords: cert signature content signing
Cc: mitja@…, dkg@… Trac Release: 0.11

Description

Hi,

An interesting feature would be electronics signing using certs of wikis, tickets, and attachments.

Besides each signature there should be a sign, that the signature is valid for given content. An additional feature would be locking, so once a user signs the content, it would get locked, unless user removes the signature or it is removed by admin.

For tickets, signing would make sense for content only (not for the comments).

Best regards, Uros.

Attachments (0)

Change History (22)

comment:1 Changed 2 years ago by rjollos

  • Component changed from Request-a-Hack to AccountManagerPlugin
  • Owner changed from anybody to hasienda

Did you intend to open this request against the AccountManagerPlugin?

comment:2 Changed 2 years ago by uros@…

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.

comment:3 Changed 2 years ago by hasienda

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.

comment:4 Changed 2 years ago by anonymous

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...

comment:5 Changed 2 years ago by hasienda

  • Component changed from AccountManagerPlugin to CryptoPlugin
  • Keywords changed from cert, signature, content, signing to cert signature content signing

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.

comment:6 Changed 2 years ago by uros@…

Great!

comment:7 Changed 2 years ago by hasienda

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

comment:8 Changed 2 years ago by hasienda

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?

comment:9 follow-up: Changed 2 years ago by rjollos

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.

comment:10 in reply to: ↑ 9 Changed 2 years ago by hasienda

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.

comment:11 Changed 2 years ago by hasienda

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.

comment:12 Changed 2 years ago by hasienda

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?

comment:13 Changed 2 years ago by hasienda

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.

comment:14 follow-up: Changed 2 years ago by rjollos

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.

comment:15 in reply to: ↑ 14 ; follow-up: Changed 2 years ago by hasienda

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.

comment:16 Changed 2 years ago by hasienda

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.

comment:17 follow-up: Changed 2 years ago by 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).

comment:18 in reply to: ↑ 15 Changed 2 years ago by rjollos

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).

comment:19 in reply to: ↑ 17 Changed 2 years ago by rjollos

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!

comment:20 Changed 2 years ago by hasienda

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.

comment:21 Changed 2 years ago by hasienda

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

comment:22 Changed 21 months ago by dkgdkg

  • Cc dkg@… added

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.