[Bug][compiler-v2] Randomness errors out for fun init_module even though it is private

[alnoki]

@brmataptos @fEst1ck @georgemitenkov @gregnazario @rahxephon89 @runtian-zhou @vineethk @wrwg

General

When I try and use randomness during init_module to initialize state using onchain randomness, the compiler errors out with:

INCLUDING DEPENDENCY AptosFramework
INCLUDING DEPENDENCY AptosStdlib
INCLUDING DEPENDENCY MoveStdlib
BUILDING InitRandom
error: only private or public(friend) entry functions can have #[randomness] attribute
  ┌─ /the_files_are_in_the_computer/init_random/sources/init_random.move:9:9
  │
9 │     fun init_module(publisher: &signer) {
  │ 

To reproduce

module publisher::init_random {
    use aptos_framework::randomness::Self;

    struct RandomNumber has key {
        number: u64,
    }

    #[randomness]
    fun init_module(publisher: &signer) {
        move_to(publisher, RandomNumber { number: randomness::u64_integer() });
    }

}

[package]
name = "InitRandom"
version = "1.0.0"

[addresses]
publisher = "_"

[dev-addresses]
publisher = "0xaaa"

[dependencies.AptosFramework]
git = "https://github.com/aptos-labs/aptos-framework.git"
rev = "mainnet"
subdir = "aptos-framework"

[georgemitenkov]

@alnoki I am not sure this is a bug. To protect randomness from test & abort or undergasing attacks, it is currently only allowed to use private entry functions. Since init_module runs after some meterd code (publish), randomness can be biased.

cc @zjma for thoughts

[wrwg]

There is the attribute lint::allow_unsafe_randomness.

[vineethk]

I think the confusion may have been from the wording: in the error message, we say "private or public(friend) entry functions" . Perhaps we should make it clearer with "entry functions that are private or public(friend)", which may have been the confusion here based on the original writeup.

[alnoki]

@vineethk thanks for the follow up

I understand from @wrwg 's comment that this is considered unsafe randomness , which implies to me that even if I could get it to compile that it would error out onchain

Does this mean that randomness is indeed unsupported during init_module calls? Is it possible to get support for this added?

I understand from @georgemitenkov 's comment that randomness attacks are of concern, but can these be mitigated by only allowing randomness on init_module calls that are the last call in some execution sequence?