cabal check errors on git://

[phadej]

The following errors are likely to affect your build negatively:
Error: [git-protocol] Cloning over git:// might lead to an arbitrary code
execution vulnerability. Furthermore, popular forges like GitHub do not
support it. Use https:// or ssh:// instead.

That won't affect build negatively when the package is fetched from Hackage. This should not be an error, at most a warning. (Like specifying -O2).

[ffaf1]

PR #10261, there has been a discussion there too.

Sources:

• Relevant section of Git Book and

• cabal/Cabal/src/Distribution/PackageDescription/Check/Warning.hs

  Lines 70 to 73 in 5ec4dd1

  	| -- | A problem that is likely to affect building the package, or an
  	-- issue that we'd like every package author to be aware of, even if
  	-- the package is never distributed.
  	PackageBuildWarning {explanation :: CheckExplanation}

Reading the Git Book, there really seems no good reason to use git://, and great risks (abritrary code execution!); definitely a thing we want to warn a user about (and incidentally definitely something I would not like to land in Hackage).

On the contrary -O2 has legitimate uses, thus check is less strict about it:

Warning: [option-o2] 'ghc-options: -O2' is rarely needed. Check that it is giving a
real benefit and not just imposing longer compile times on your users.

Can you tell us more about your use case?

[phadej]

Can you tell us more about your use case?

Old package had git://. Suddenly cabal check started to fail.

Reading the Git Book, there really seems no good reason to use

Currently, the only use case for source-repository in .cabal file is informative. I'd be surprised if anyone uses it any automatic way. Hard failing just because the informative field is missing is bad. You don't fail if maintainer field (another informative field) is missing or isn't an email address or ...

[ulysses4ever]

I'd be surprised if anyone uses it any automatic way

I seem to remember @mpickering and/or @alt-romes using this field in an automatic way when testing the new project file parser iirc.

[ffaf1]

Yes I suspect cabal get -s uses that.

In general, even if the user is only cutting and pasting that to feed it to git clone, I see the mild, one-time inconvenience of a package maintainer versus the risk of arbitrary code execution for users.

[phadej]

Yes I suspect cabal get -s uses that.

The cabal get should then warn / abort if it's going to do something unsafe. If it does, then fine, cabal check can error on git:// in source-repository; otherwise that error is hypocritical.

[ffaf1]

That makes sense.

I can look into that, if you open a new issue.