Currently, the .security.txt takes away quite some bytes to store the information, since everything originially is in string format.

What could be done to further improve this is using a serialisation protocol, preferably borsch, to serialise the entire security.txt key:value pairs.

• Each pre-defined key is an unsigned 1-byte integer, giving use upto 255 keys to use. e.g., name - 0x01, project_url - 0x02, etc.

• Now, to identify the HEADER and FOOTER we use a 6 byte magic number to indentify the same.

  HEADER = 0xDEC1A551F1ED (hex-word play on Declassified) FOOTER = 0xEDF151A5C1DE (little-endian byte swap (HEADER))

  HEADER + serialised security.txt + FOOTER

• For the encryption key part, having PGP makes total sense to communicate securely with the contract dev. Just not sure about an external link so much. Finality of the pgp public key as a string with the recently deployed code makes more sense. Default recommendation to the dev can be to provide the PGP public key!

Note: For any upgradeable smart contract on Solana the change in the spec of security.txt doesn't effect the eBPF bytecode exec, or anything for the smart contract devs.

Although a minimum coordination may be requied with the Explorer services that are using this.

Would love to hear you thoughts on this @CherryWorm!

After adding a security_txt! in my src/lib.rs, cargo build and cargo test begin to fail with this error:

LLVM ERROR: Global variable 'security_txt' has an invalid section specifier '.security.txt': mach-o section specifier requires a segment and section separated by a comma.

cargo +bpf build --target bpfel-unknown-unknown --release (which is being called by anchor build) does seem to work without issues even with the macro left in though

Copying the macro directly into the code and removing the #[link_section] line also works fine

#[macro_export]
macro_rules! security_txt {
    ($($name:ident: $value:expr),*) => {
        #[allow(dead_code)]
        #[no_mangle]
        // #[link_section = ".security.txt"] // removing this works
        pub static security_txt: &str = concat! {
            "=======BEGIN SECURITY.TXT V1=======\0",
             $(stringify!($name), "\0", $value, "\0",)*
            "=======END SECURITY.TXT V1=======\0"
        };
    };
}

When compiling multiple Anchor programs from the same workspace, we get this error.

error: linking with `rust-lld` failed: exit status: 1

# omitted

  = note: rust-lld: error: duplicate symbol: security_txt

Directory structure:

programs/
├── program-1
│   ├── Cargo.toml      # solana-security-txt = "1.0.1"
│   └── src
├── program-2
│   ├── Cargo.toml      # solana-security-txt = "1.0.1"
│   └── src
└── program-3
    ├── Cargo.toml      # solana-security-txt = "1.0.1"
    └── src

When we set the dependency in only 1 program we do not get the error.

Note; the error occurs when we use the crate and try the utilize the macro, like so

use solana_security_txt::security_txt;

security_txt! {
// omitted
}

EDIT

Upon further checking, it seems other programs inherit the security txt setting when they have dependency with a program that already has a security-txt

In below example, program-2 inherits the security-txt settings from program-1 and cannot set it's own. Also block explorers show the wrong entry.

programs/
├── program-1
│   ├── Cargo.toml      # solana-security-txt = "1.0.1"
│   └── src
└── program-2
    ├── Cargo.toml      # program-1 = { path = "../program-1", features = ["cpi"] }
    └── src

Are we doing something wrong, or is this unintended behaviour?

We would like to have a unique security report for each of our programs and have them depend on each other for CPI purposes.

Thanks in advance!

This addresses #11:

When using another smart-contract as dependency it also generates it's security.txt. The compiler is helpful here and prevents two conflicting security.txt being present.

Dependencies have to omit emitting the security.txt. Solana contracts already use the no-entrypoint feature to avoid including entrypoints of dependent smart-contracts, this can easily be adapted here.

We have brainstormed a bit, but there doesn't seem to be a fool-proof solution for solving this automatically. So there isn't much we can do about that from the perspective from this crate. The decision to include or not include the macro always has to happen from the caller, and we cannot introspect if the parent is compiled with no-entrypoint.

This aspect is currently lacking from the documentation, working on a pull-request to fix this, and make it very clear that if you expect to be included as dependency and have an exposed no_entrypoint feature, you have to put the security.txt under that as well:

#[cfg(not(feature = "no-entrypoint"))]
security_txt! {
...
}

Unfortunately, this issue means contracts that currently do not do this cannot be used as a dependency until they are updated.

Discussion moved to https://github.com/yarnpkg/rfcs/pull/37

Originally posted by @CrabDude in https://github.com/yarnpkg/yarn/issues/2241#issuecomment-271366221

Agreed. Should be fairly simple to do. Out of interest, are you aware of any larger contracts except for Pyth that are written in C? It seems of the currently ~2.5k deployed contracts, only 64 are written in C. (found via ELF contains llvm-project.git)

Originally posted by @tlambertz in https://github.com/neodyme-labs/solana-security-txt/issues/1#issuecomment-1083231546

We could add a new optional "forked-from-repo" field to easily indicate when a project is based on another.

In case a bug is found, this field would allow to easily find related projects, which might have similar security issues.