Added security.txt metadata into build

[galekseev]

No description provided.

[github-actions]

Summary of Code Changes:

The pull request adds security metadata to the fusion-swap and whitelist programs by integrating the solana-security-txt crate. Specifically, it:

• Adds the solana-security-txt dependency to both programs in their Cargo.toml files.
• Updates the version numbers of both programs from 0.1.0 to 1.0.0 in Cargo.toml and Cargo.lock.
• Introduces security metadata in src/lib.rs of both programs using the solana_security_txt::security_txt! macro.
• Adds docker-target to .gitignore to exclude Docker build artifacts.

Issues and Actionable Suggestions:

1. Empty policy Field in Security Metadata:

   • Issue: The policy field within the solana_security_txt::security_txt! macro is set to an empty string.
   • Implication: The policy field is required and should contain the project's security disclosure policy. Leaving it empty may lead to warnings or non-compliance with expected standards.
   • Suggestion: Provide a valid security disclosure policy URL or text. For example:

     policy: "https://1inch.io/security-disclosure-policy",

     Or, if the policy is lengthy, include a brief statement and reference:

     policy: "Please refer to our security policy at https://1inch.io/security-policy.",

2. Consistency of Version Numbers and Source Release:

   • Issue: The source_release in the security metadata is specified as "1.0.0-release", while the program versions are updated to "1.0.0". Additionally, the source_revision is set to a specific commit hash.
   • Implication: Inconsistencies between version numbers can cause confusion about the exact version of the source code referenced.
   • Suggestion: Ensure that the source_release matches the version specified in Cargo.toml. Update it to:

     source_release: "1.0.0",

     Also, verify that the source_revision corresponds to the commit associated with this release. If the commit hash will change upon merging, consider automating the insertion of the correct hash during the build process or updating it accordingly.

3. Placement of Security Metadata Macro:

   • Issue: The solana_security_txt::security_txt! macro is placed after the use statements and before the declare_id! macro.
   • Implication: While this placement is functionally acceptable, placing macros and declarations in a consistent order enhances code readability.
   • Suggestion: For better readability, consider placing the security metadata macro after the declare_id! macro or grouping all macros together. Example:

     use error::FusionError;
     
     declare_id!("HNarfxC3kYMMhFkxUFeYb8wHVdPzY5t9pupqW5fL2meM");
     
     #[cfg(not(feature = "no-entrypoint"))]
     solana_security_txt::security_txt! { ... }

Conclusion:

The additions effectively incorporate security metadata into both programs, enhancing transparency and security compliance. Addressing the above issues will ensure that the metadata is complete, accurate, and maintains consistency throughout the codebase.