yavsc/src/Yavsc.Org/AssemblyInfo.cs

using Microsoft.Extensions.Localization;
using System.Runtime.CompilerServices;

[assembly: RootNamespace("Yavsc")]

// Expose internals to the Yavsc.Org.Tests project so unit tests can
// reach the signing-credential loader (LoadSigningCredentials / kid
// derivation) without going through the full IdentityServer boot.
[assembly: InternalsVisibleTo("Yavsc.Org.Tests")]
refactoring the Register 2026-02-22 23:39:56 +00:00			`using Microsoft.Extensions.Localization;`
test(yavsc.org): cover the kid derivation in ComputeKid Extract the kid calculation out of LoadSigningCredentialsInner into a new internal static HostingExtensions.ComputeKid(string), and cover it with five focused unit tests in Yavsc.Org.Tests.ComputeKidTests. The kid is the bit of signing-credential metadata that ties a JWT to the right key in the JWKS. Without it, resource servers (Yavsc.Blogs, Yavsc.Api) fail signature validation with IDX10500 'The signature key was not found', as fixed in 2c6d1157. That fix inlined three lines of thumbprint-truncation logic at the top of LoadSigningCredentialsInner, but left the calculation untested. The tests in this commit pin its shape, value, stability, and uniqueness, so a future refactor (e.g. switching from SHA-1 to SHA-256, or moving to X509CertificateLoader for SYSLIB0057) has to update them deliberately instead of silently changing the JWKS key id. Concretely: - InternalsVisibleTo("Yavsc.Org.Tests") in AssemblyInfo.cs gives the test project access to the new internal method without forcing LoadSigningCredentialsInner to leak further. - ComputeKid(string) is the single source of truth for the 16-hex truncation; the production call site in LoadSigningCredentialsInner now reads 'var kid = ComputeKid(certPath);'. - The inline comment block is updated to say SHA-1 (which is what X509Certificate2.GetCertHash() actually returns) instead of the previous SHA-256 claim. The behaviour is unchanged. - ComputeKid uses X509CertificateLoader.LoadCertificateFromFile rather than the obsolete 'new X509Certificate2(string)' ctor (SYSLIB0057); same on-disk behaviour, no obsolete warning. Tests cover: - 16-char upper-case hex output matching the first 16 hex chars of the cert's GetCertHash(); - stability across repeated reads of the same cert; - distinctness between two independently generated certs; - the SHA-1 size of the underlying thumbprint (20 bytes), so a future switch to SHA-256 forces a test update; - CryptographicException propagation for a missing cert file (Assert.ThrowsAny to stay portable across the Linux OpenSSL and Windows leaf exception types). 2026-07-09 20:28:58 +01:00			`using System.Runtime.CompilerServices;`
refactoring the Register 2026-02-22 23:39:56 +00:00
			`[assembly: RootNamespace("Yavsc")]`
test(yavsc.org): cover the kid derivation in ComputeKid Extract the kid calculation out of LoadSigningCredentialsInner into a new internal static HostingExtensions.ComputeKid(string), and cover it with five focused unit tests in Yavsc.Org.Tests.ComputeKidTests. The kid is the bit of signing-credential metadata that ties a JWT to the right key in the JWKS. Without it, resource servers (Yavsc.Blogs, Yavsc.Api) fail signature validation with IDX10500 'The signature key was not found', as fixed in 2c6d1157. That fix inlined three lines of thumbprint-truncation logic at the top of LoadSigningCredentialsInner, but left the calculation untested. The tests in this commit pin its shape, value, stability, and uniqueness, so a future refactor (e.g. switching from SHA-1 to SHA-256, or moving to X509CertificateLoader for SYSLIB0057) has to update them deliberately instead of silently changing the JWKS key id. Concretely: - InternalsVisibleTo("Yavsc.Org.Tests") in AssemblyInfo.cs gives the test project access to the new internal method without forcing LoadSigningCredentialsInner to leak further. - ComputeKid(string) is the single source of truth for the 16-hex truncation; the production call site in LoadSigningCredentialsInner now reads 'var kid = ComputeKid(certPath);'. - The inline comment block is updated to say SHA-1 (which is what X509Certificate2.GetCertHash() actually returns) instead of the previous SHA-256 claim. The behaviour is unchanged. - ComputeKid uses X509CertificateLoader.LoadCertificateFromFile rather than the obsolete 'new X509Certificate2(string)' ctor (SYSLIB0057); same on-disk behaviour, no obsolete warning. Tests cover: - 16-char upper-case hex output matching the first 16 hex chars of the cert's GetCertHash(); - stability across repeated reads of the same cert; - distinctness between two independently generated certs; - the SHA-1 size of the underlying thumbprint (20 bytes), so a future switch to SHA-256 forces a test update; - CryptographicException propagation for a missing cert file (Assert.ThrowsAny to stay portable across the Linux OpenSSL and Windows leaf exception types). 2026-07-09 20:28:58 +01:00
			`// Expose internals to the Yavsc.Org.Tests project so unit tests can`
			`// reach the signing-credential loader (LoadSigningCredentials / kid`
			`// derivation) without going through the full IdentityServer boot.`
			`[assembly: InternalsVisibleTo("Yavsc.Org.Tests")]`