anchor.diff:  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.
  -====
  +
  +Gradle won't verify either checksums or signatures of plugins which use their own HTTP clients.
  +Only plugins which use the infrastructure provided by Gradle for performing requests will see their requests verified.
  +====
  +
  +If an included build is used:
  +
  +- the configuration file of the _current_ build is used for verification
  +- so if the included build itself uses verification, its configuration is ignored in favor of the current one
  +- which means that including a build works similarly to upgrading a dependency: it may require you to update your current verification metadata
   
   [[sec:verification-dry-mode]]
   === Using dry mode
   
  +By default, bootstrapping is incremental, which means that if you run it multiple times, information is _added_ to the file and in particular you can rely on your VCS to check the diffs.
   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`:
  
positive.code: 
  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.
  
  However:
  
  - Gradle only supports verification of signatures published on remote repositories as ASCII-armored PGP files
  - Not all artifacts are published with signatures
  
  As a consequence, signature verification will often be used alongside checksum verification.
  
  
negative.code: - later on, the key is stolen and used to sign artifact `B`
  
  It means you can trust the key `A` for the first artifact, probably only up to the released version before the key was stolen, but not for `B`.
  
  Remember that anybody can put arbitrary name when generating PGP key, so never trust the key solely based on the key name.
  Verify if the key is listed at the official site.
  For example, Apache projects typically provide a KEYS.txt file that you can trust.
  ====
  
  [[sec:ignoring-keys]]
  