anchor.diff:  
   In addition to <<sec:checksum-verification,checksums>>, Gradle supports verification of signatures.
   Signatures are used to assess the _provenance_ of a dependency (it tells who signed the artifacts, which usually corresponds to who produced it).
  -They are also used to assess the integrity of a dependency just like checksums.
  +
   While enabling signature verification usually means a higher level of security, you might want to replace checksum verification with signature verification.
  +
  +[WARNING]
  +====
  +Signatures _can_ also used to assess the integrity of a dependency similarly to checksums.
  +Signatures are signatures of the _hash_ of artifacts, not artifacts themselves.
  +This means that if the signature is done on an _unsafe hash_ (even SHA1), then you're not correctly assessing the _integrity_ of a file.
  +For this reason, if you care about both, you need to add both signatures _and_ checksums to your verification metadata.
  +====
   
   However:
   
   - Gradle only supports verification of signatures published on remote repositories as ASCII-armored PGP files
   - Not all artifacts are published with signatures
  +- A good signature doesn't mean that the signatory was legit
   
   As a consequence, signature verification will often be used alongside checksum verification.
   
  
positive.code: As a matter of fact, Gradle cannot automatically discover _detached configurations_, which are basically dependency graphs resolved as an internal implementation detail of the execution of a task: they are not, in particular, declared as an input of the task because they effectively depend on the configuration of the task at execution time.
  
  A good way to start is just to use the simplest task, `help`, which will discover as much as possible, and if subsequent builds fail with a verification error, you can re-execute generation with the appropriate tasks to "discover" more dependencies.
  ====
  
  [[sec:verification-dry-mode]]
  === Using dry mode
  
  There are situations where you would just want to _see_ what the generated verification metadata file would look like without actually changing the existing one or overwriting it.
  
  For this purpose, you can just add `--dry-run`:
  
negative.code: $ gpg --no-default-keyring --keyring gradle/verification-keyring.gpg --recv-keys 379ce192d401ab61
  
  gpg: keybox 'gradle/verification-keyring.gpg' created
  gpg: key 379CE192D401AB61: public key "Bintray (by JFrog) <****>" imported
  gpg: Total number processed: 1
  gpg:               imported: 1
  
  $ gpg --no-default-keyring --keyring gradle/verification-keyring.gpg --recv-keys 6a0975f8b1127b83
  
  gpg: key 0729A0AFF8999A87: public key "Kotlin Release <****>" imported
  gpg: Total number processed: 1
  gpg:               imported: 1
  ----
  