Vignere cipher does not specify any property strings

[mattcaswell]

At the very least I'd expect it to have "provider=vignere" specified for it.

[levitte]

I see no compelling reason why... there are no competing implementations as far as I know, and even if there were, I couldn't be bothered as long as they have the same inputs and outputs.

Of course, if there were multiple implementations with other compelling properties, such as an assembler implementation ('cause of course we'd need an assembler implementation of this example, right :wink:), that implementation might wisely want to add the property "x.asm=yes" or something like that, so application could choose to fetch the assembler version specifically.

[levitte]

If this would turn out to be an actual problem, of course I can reconsider (and considering the nature of this provider, I'd be quite surprised!).

[mattcaswell]

My reasoning for wanting this:

• I think it is good practice that we should encourage all provider authors to supply at least this one property string with their algorithms. We have in many places and on many occasions stated that users can select which providers to use by specifying the "provider=..." property query string. Users will expect that third party providers will work in the same way.
• Of course it is obvious that, by definition, the first implementation will never have a competing implementation. But as soon as a second implementation does come along it is desirable that the first implementation should already have this property string in place
• The whole purpose of the Vignere provider is to supply a simple "Hello World" style implementation of a provider. I found myself answering a question from a provider author who was implementing a replacement algorithm for one in the default provider. The answer to the question was "make sure you have defined a property string for your algorithm so that it can be selected". I wanted to link to a simple example of how to do that, so my first thought was to point at the Vignere provider. But then I discovered that the Vignere provider doesn't do that either.

[levitte]

Hmmm... I can in a way see how that works as an example. However, even though I haven't voiced that very loudly, I find the "provider=" property quite lousy, for a very simple reason: someone else might create a provider module vigenere.so, and there's nothing to stop them doing so. Of course, that author would probably also use the property "provider=vigenere"... and I suppose you get to watch your scheme crumble into bits :wink:

So, it we really want to look at a compelling identifier, I think we need to rethink the strategy. Just top of my head, I could go with an authorship identifier. Say, "x.author=provider-corner" or "x.author=richard@levitte.org"?

[levitte]

Side note re "x.": I'm inspired by the unofficial email headers that start with X-

[levitte]

There is now a new commit going along with the "x.author" idea.

[levitte]

... and did the same with the extra provider

[mattcaswell]

I still maintain that it should be considered best practice for all provider authors to implement the "provider=" property.

someone else might create a provider module vigenere.so, and there's nothing to stop them doing so.

This doesn't seem to be that big a deal. Yes that could theoretically happen - but isn't there only one location where such modules are loaded from? So two modules with the same name in the same place doesn't seem possible (at least on most common filesystems), i.e. you wouldn't be able to load two modules with the same name in the first place so clashing of names in property query string seems like it doesn't really matter. Maybe there needs to be some convention on what provider authors can call their modules to avoid clashes, but that seems like a bit of a tangential problem to this issue.

That said the change you made does solve the immediate issue that I saw (i.e. a lack of an example of properties, and a way to disambiguate which implementation you actually meant). I'm not sure that making up a new identifier is a good idea to achieve that when we already have a perfectly good one ("provider").

I'm also not sure the "x" prefix is that great an idea. From the "property" man page:

A user defined property name is similar, but it must consist of two or more C-style identifiers, separated by periods. The last identifier in the name can be considered the 'true' property name, which is prefixed by some sort of 'namespace'. Providers for example could include their name in the prefix and use property names like

So the name before the "." is supposed to be a "namespace". Something like "provider-corner" might be a better namespace - but just "x" isn't great.

[mouse07410]

I second what Matt said.

The whole - the only - purpose of this provider is to show others (in a simplified way) how a usable/useful provider can be written.

Thus, if this example lacks parts/components that a "real" provider (RSA, Kyber, PKCS#11) would need to include - IMHO, it misses the mark.

As I recall, the "engine example" included sample engines for RSA and MD5, covering "sufficient" spectrum.

Provider interface is more complex, so IMHO it needs at least that much.

[levitte]

Side note: it seems I've found a bug in the property parsing code. It doesn't seem to like "x.author", and I can't see anything in the specs that would make that invalid

[levitte]

Side note: it seems I've found a bug in the property parsing code. It doesn't seem to like "x.author", and I can't see anything in the specs that would make that invalid

Found and fixed: openssl/openssl#19998

[levitte]

As I recall, the "engine example" included sample engines for RSA and MD5, covering "sufficient" spectrum.

Provider interface is more complex, so IMHO it needs at least that much.

You're over complicating the intention with this provider; it is meant to demonstrate a really minimum provider, and the possibility to add an algorithm that OpenSSL knows nothing about in any way or form.

Of course it's possible to write providers that re-implement algorithms that OpenSSL provides. This provider isn't it. Other providers that do what you ask are welcome, though (here, in OpenSSL itself or as other separate projects).

[t8m]

IMO it would be best if the provider=<provider-name> was an implicit property of every fetchable algorithm. You cannot load two different providers with a same name, so there is no way this could conflict.

[levitte]

It seems that some discussion on this topic needs to happen between OpenSSL developers, and even though I'm one of them, this is not really the spot for that discussion...

[levitte]

I'm also not sure the "x" prefix is that great an idea. From the "property" man page:

A user defined property name is similar, but it must consist of two or more C-style identifiers, separated by periods. The last identifier in the name can be considered the 'true' property name, which is prefixed by some sort of 'namespace'. Providers for example could include their name in the prefix and use property names like

So the name before the "." is supposed to be a "namespace". Something like "provider-corner" might be a better namespace - but just "x" isn't great.

I disagree with that position. x. is just as great a namespace as the X- "namespace" for email headers, and has exactly the same purpose, to be an unofficial property name prefix that anyone can use with no special owner.

[levitte]

At this point, there is a property, even though not exactly the one asked for. I believe that's enough to close this issue.