move license verification to license package

[aead]

This commit adds the license package and removes the licverifier and subnet packages. The new
license package exposes a simpler API for verifying licenses that is better suited for conditional compilation.

Ideally, license verification should only happen for release builds. Hence, license verification code can be guarded by a build directive.

//go:build !dev

[anjalshireesh]

We may need some mechanism to get new key in case it changes on SUBNET side.

[aead]

You would only ever want to change a key if it is compromised. If that is the case, the new key should be added here and this one should be removed (after a grace period). It seems reasonable to expect people to upgrade within this timeframe.

Dynamically fetching the key allows someone intercepting the network traffic to replace it and craft their own custom licenses.

[anjalshireesh]

so if the key is indeed compromised and hence changed on SUBNET,

• All products doing license verification must immediately be released with the new key (as existing versions will fail verification of newly generated licenses)
• Any existing customer whose license has expired (and grace period also over) must upgrade to the new version after getting their license extended/renewed (as the new license will be generated with new key)

Is this ok @harshavardhana ?

If we don't want to enforce upgrade in these situations, one option could be to allow the customer to override the public key by setting the new one in an env or standard file path.

[harshavardhana]

We have to provide fallbacks when that happens so we can have two keys at a time. The one that we always use , and the one that can be injected freshly into the implementation.

[aead]

All products doing license verification must immediately be released with the new key (as existing versions will fail verification of newly generated licenses)

All products must be released with a single dep change: Upgraded minio/pkg. This can be done as a regular release or (if not possible at the moment) from the latest stable with a backport. Also, there is no "immediate" action required since the key is compromised and any existing binary / container image can still be used. This is more on us than the users/customers.

Any existing customer whose license has expired (and grace period also over) must upgrade to the new version after getting their license extended/renewed (as the new license will be generated with new key)

Technically yes. However, in cases where this is not possible we could make an exception and provide a license signed with the compromised key.

If we don't want to enforce upgrade in these situations, one option could be to allow the customer to override the public key by setting the new one in an env or standard file path.

This is even worse then allowing the key to be fetched from the network. If you can provide your own public key for verifying the binary, then you just create a private/public key pair, issue an arbitrary license with the private key and provide the public key you just generated.

[anjalshireesh]

Also, there is no "immediate" action required since the key is compromised and any existing binary / container image can still be used. This is more on us than the users/customers.

Existing binary cannot be used by new customers because their license would have been created with the new key and hence would fail verification by existing binary.

[aead]

Let's assume our private signing key K1 gets compromised.
Now, someone can issue arbitrary licenses that any existing
binary considers valid. Hence, we switch to K2 and start
issue licenses with it from now on.

Now, there are:

• Users running existing binaries with licenses issued by K1.
  This is fine.
• Users running existing binaries with licenses issued by K2.
  This might be a problem.
• Users running new binaries with licenses issued by K1.
  This might be a problem.
• Users running new binaries with licenses issued by K2.
  This is fine.

When a user has a license issued by K1 and upgrades its binary
to a version requiring K2 then the user has to update its license.
This is always the case.

When a user has a license isssued by K2 and tries to run a
an existing binary then P2 (public key) must be already in
the binary or it will not work. Otherwise, the user is forced to
upgrade.

Hence, putting a 2nd public key (P2) into the binaries now
allows users to update their license without upgrading their
binaries. However, this requires that K2 is stored separatley
from K1 (e.g. offline).

An alternative approach would be to issue the license based
on the user's binary version. If the binary still requires a
license issued by K1 we can issue one. Nothing prevents
that.

In any case, users who upgrade will require a new license eventually
because newer versions don't honor their exisiting license. However,
users who don't upgrade require a new license once their current one
expires. At this point they either have to upgrade or we put a 2nd public
key in now, or we issue licenses using K1 for them.

[aead]

Existing binary cannot be used by new customers because their license would have been created with the new key and hence would fail verification by existing binary.

What I'm trying to say is that a customer does not have to upgrade immediately. We only start issuing new licenses when releases are ready - not as soon as we notice that the key got compromised. Once new releases are ready, new customers will use them most probably. (Special cases can be taken care of). There is no point in changing the key as long as there are no releases that can verify it.

Also note that if there is a user who cannot upgrade their deployment for some reason but has to upgrade their license then we can always issue the license with the current (hyp. compromised) key.

[aead]

Closing this in favour of a separate package as discussed with @donatello @shtripat and @abperiasamy