Usage of floating pragma

[hats-bug-reporter]

Github username: @@giorgiodalla
Twitter username: 0xAuditism
Submission hash (on-chain): 0xf8de327cbd43eb23fcf2c5b769f076dc475ce3cae496ff82150905b23006f7a1
Severity: low

Description:
Description
All contracts in scope have flaoting pragma.
Pragma directives should be fixed to clearly identify the Solidity version with which the contracts will be compiled.
Note that libraries can still be used with floating pragmas.

Attack Scenario
Describe how the vulnerability can be exploited.

Attachments

1. Proof of Concept (PoC) File

@> pragma solidity >=0.8.0;

import {SignatureValidator} from "../base/SignatureValidator.sol";
import {ISafe} from "../interfaces/ISafe.sol";
import {P256, WebAuthn} from "../libraries/WebAuthn.sol";

/**
 * @title Safe WebAuthn Shared Signer
 * @dev A contract for verifying WebAuthn signatures shared by all Safe accounts. This contract uses
 * storage from the Safe account itself for full ERC-4337 compatibility.
 */
contract SafeWebAuthnSharedSigner is SignatureValidator {

2. Revised Code File (Optional)
   Consider adding fixed pragmas, this can be done such as:

-pragma solidity >=0.8.0;
+pragma solidity >=0.8.0;
import {SignatureValidator} from "../base/SignatureValidator.sol";
import {ISafe} from "../interfaces/ISafe.sol";
import {P256, WebAuthn} from "../libraries/WebAuthn.sol";

/**
 * @title Safe WebAuthn Shared Signer
 * @dev A contract for verifying WebAuthn signatures shared by all Safe accounts. This contract uses
 * storage from the Safe account itself for full ERC-4337 compatibility.
 */
contract SafeWebAuthnSharedSigner is SignatureValidator {

[nlordell]

Thank you, while I do believe there is merit to the proposal, I don't believe that there is a clear need for using fixed Solidity contract pragmas. In fact we don't use them in the Safe core contracts. There are trade-offs to both approaches. Furthermore, the project includes documentation about the exact compiler version that is used, and verified code explorers like Sourcify and Etherscan clearly show the Solidity version the contract was compiled with.

I personally see this as a "coding style" suggestion which I don't think is in scope for the audit competition and as such will mark it as invalid.

[auditism]

I respect your choice and thank you for giving such a detailed explanation, I do appreciate that.
The reason I did submit this low issue is because all contracts besides one had a floating pragma. So I thought that it was an oversight on your part, since if it was a coding style choice there would have been consistency.
Anyways it is true that the impact is non existent and is considered a best practice, but in most audit contest it is still a valid low.

[nlordell]

Thank you for your reply.

I agree with you that the pragmas are inconsistent. In fact some contracts use ranges, others use ^ and others use unbounded ranges.

The decision to use floating pragmas was also re-evaluated by our team and we decided to implement your suggestion (as well as make other pragmas consistent throughout the code - making sure that the minimum version is indeed the minimum version that the contracts build with).

As such, we have reconsidered and will be awarding this as a "low" find. Thanks for your submission!

[0xEricTee]

@nlordell Reviewed the fix and the amendment looks fine, thanks!