Bug 93233 - trust list: show trusted purpose and origin
Summary: trust list: show trusted purpose and origin
Status: NEW
Alias: None
Product: p11-glue
Classification: Unclassified
Component: p11-kit (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Stef Walter
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-03 20:15 UTC by Kai Engert
Modified: 2015-12-07 11:21 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
experiment v1 (1.62 KB, patch)
2015-12-03 20:15 UTC, Kai Engert
Details | Splinter Review

Description Kai Engert 2015-12-03 20:15:00 UTC
I'm trying to learn how to enhance the output of the "trust list" command, and made a few experiments.

I'd like it to show the trusted purpose and the origin (file) where an object came from.

BTW, "man trust" offers filtering by usable purpose.
Is that really about "being usable" (e.g. by certificate attributes)?
Or is it rather about "marked as trusted for this purpose" or "marked as trusted for any purpose"?
Or is it both?

That might be nice to clarify.


Back to my enhancement attempt. I'll attach an experimental patch.

The part that prints the trusted-for information seems to work.

The part that prints the origin information doesn't work, nothing is printed. I saw in other parts of the code that the origin is added as an attribute when objects are loaded, using CKA_X_ORIGIN.

However, when iterating through the objects for printing, those attributes are missing.

Could you please give me a hint what I'd have to do to find the origin?

(The origin output can e.g. help to learn if a certificate was added as part of some installed package, or by manual, local configuration.)

Thanks in advance for your help.
Comment 1 Kai Engert 2015-12-03 20:15:44 UTC
Created attachment 120315 [details] [review]
experiment v1
Comment 2 Kai Engert 2015-12-03 20:31:52 UTC
BTW, I'd also interested in your general feedback, if you'd be OK with enhancing the output of "trust list".

In case you don't like the idea, no problem, but still, I'd like to learn how to write code that produces that information.
Comment 3 Stef Walter 2015-12-07 11:08:40 UTC
Comment on attachment 120315 [details] [review]
experiment v1

Review of attachment 120315 [details] [review]:
-----------------------------------------------------------------

::: trust/list.c
@@ +143,5 @@
>  		else
>  			printf ("    trust: unspecified\n");
>  
> +		if (!ex->purposes) {
> +				printf ("    trusted-for: all-purposes\n");

Is the goal for this to be machine readable? It may be that we list the known purposes as well here? Depends on the use case, of course.

@@ +146,5 @@
> +		if (!ex->purposes) {
> +				printf ("    trusted-for: all-purposes\n");
> +		}
> +		else for (i = 0; i < ex->purposes->num; i++) {
> +			if (0==strcmp(ex->purposes->elem[i], P11_OID_EMAIL_PROTECTION_STR)) {

Before this gets merged, we'd probably want to fix the coding style:

 * Numeric == comparison would go after the function.
 * Spaces around binary operators.
 * Close brace would go on same line as 'else' statement.

@@ +162,5 @@
> +			else
> +				printf("     trusted-for: %s\n", (const char*)ex->purposes->elem[i]);
> +		}
> +
> +		attr = p11_attrs_find (ex->attrs, CKA_X_ORIGIN);

I couldn't see any output here. This is how my p11-kit is built:

./configure --prefix=/usr --enable-strict --enable-debug --enable-coverage --enable-doc --with-trust-paths=/etc/pki/ca-trust/source:/usr/share/pki/ca-trust-source --with-hash-impl=freebl

Do you see this line attribute present anywhere?

@@ +165,5 @@
> +
> +		attr = p11_attrs_find (ex->attrs, CKA_X_ORIGIN);
> +		if (attr != NULL) {
> +			origin = strndup (attr->pValue, attr->ulValueLen);
> +				printf("     origin: %s\n", origin);

If you like you can use:

	printf(" origin: %.*s\n", (int)attr->ulValueLen, (char *)attr->pValue);
Comment 4 Stef Walter 2015-12-07 11:21:34 UTC
(In reply to Kai Engert from comment #0)
> I'm trying to learn how to enhance the output of the "trust list" command,
> and made a few experiments.

Nice. I think this is good. Showing "trust" without showing its purpose doesn't show the whole picture.

> I'd like it to show the trusted purpose and the origin (file) where an
> object came from.
>
> BTW, "man trust" offers filtering by usable purpose.
> Is that really about "being usable" (e.g. by certificate attributes)?
> Or is it rather about "marked as trusted for this purpose" or "marked as
> trusted for any purpose"?
> Or is it both?

I think it's the latter. The former would probably require building a whole certificate chain, right? It's hard to make assumptions about usability without it, especially since (as far as I know) any included certificate authority extended usage attributes are not relevant in such a scenario, only the leaf certificate extended usage attributes take effect.

> That might be nice to clarify.
> 
> 
> Back to my enhancement attempt. I'll attach an experimental patch.
> 
> The part that prints the trusted-for information seems to work.
> 
> The part that prints the origin information doesn't work, nothing is
> printed. I saw in other parts of the code that the origin is added as an
> attribute when objects are loaded, using CKA_X_ORIGIN.
> 
> However, when iterating through the objects for printing, those attributes
> are missing.
> 
> Could you please give me a hint what I'd have to do to find the origin?

Ah right, sorry for the silly comment on the review patch. My guess is that this needs to be added to extract_info() function in trust/enumerate.c

Does that do the trick?

> 
> (The origin output can e.g. help to learn if a certificate was added as part
> of some installed package, or by manual, local configuration.)
> 
> Thanks in advance for your help.

(In reply to Kai Engert from comment #2)
> BTW, I'd also interested in your general feedback, if you'd be OK with
> enhancing the output of "trust list".
> 
> In case you don't like the idea, no problem, but still, I'd like to learn
> how to write code that produces that information.

I like the idea. My only functional concern would be to try and make the listing of purposes be machine readable ... unless that's an explicit non-use-case. That may mean expanding 'all purposes'


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.