mirrors/bitcoin
1
0
Fork 0
mirror of https://github.com/bitcoin/bitcoin.git synced 2024-11-19 01:42:58 +01:00
Code Issues Projects Releases Wiki Activity
master
bitcoin/contrib/verify-binaries/README.md

91 lines
3.4 KiB
Markdown
Raw Permalink Normal View History

[contrib] Remove reference to sf and add doc to verify.sh
2016-04-15 12:18:12 +02:00
### Verify Binaries
[contrib] verifybinaries: Mention mandatory preparation step
2016-08-21 21:58:29 +02:00
contrib: verifybinaries: allow multisig verification This commit adds the functionality necessary to transition from doing binary verification on the basis of a single signature to requiring a minimum threshold of trusted signatures. A signature can appear as "good" from GPG output, but it may not come from an identity the user trusts. We call these "good, untrusted" signatures. We report bad signatures but do not necessarily fail in their presence, since a bad signature might coexist with enough good, trusted signatures to fulfill our criteria. If "--import-keys" is enabled, we will prompt the user to optionally try to retrieve unknown keys. Marking them as trusted locally is a WIP, but keys which are retrieved successfully and appear on the builder-keys list will immediately count as being useful towards fulfilling the threshold. Logging is improved and an option to output JSON that summarizes the whole sum signature and binary verification processes has been added. Co-authored-by: Russ Yanofsky <russ@yanofsky.org> Co-authored-by: willcl-ark <will8clark@gmail.com>
2021-09-17 00:33:20 +02:00
#### Preparation
[contrib] verifybinaries: Mention mandatory preparation step
2016-08-21 21:58:29 +02:00
contrib: verifybinaries: allow multisig verification This commit adds the functionality necessary to transition from doing binary verification on the basis of a single signature to requiring a minimum threshold of trusted signatures. A signature can appear as "good" from GPG output, but it may not come from an identity the user trusts. We call these "good, untrusted" signatures. We report bad signatures but do not necessarily fail in their presence, since a bad signature might coexist with enough good, trusted signatures to fulfill our criteria. If "--import-keys" is enabled, we will prompt the user to optionally try to retrieve unknown keys. Marking them as trusted locally is a WIP, but keys which are retrieved successfully and appear on the builder-keys list will immediately count as being useful towards fulfilling the threshold. Logging is improved and an option to output JSON that summarizes the whole sum signature and binary verification processes has been added. Co-authored-by: Russ Yanofsky <russ@yanofsky.org> Co-authored-by: willcl-ark <will8clark@gmail.com>
2021-09-17 00:33:20 +02:00
As of Bitcoin Core v22.0, releases are signed by a number of public keys on the basis
of the [guix.sigs repository](https://github.com/bitcoin-core/guix.sigs/). When
verifying binary downloads, you (the end user) decide which of these public keys you
trust and then use that trust model to evaluate the signature on a file that contains
hashes of the release binaries. The downloaded binaries are then hashed and compared to
the signed checksum file.
Finished /Contrib Index. Standardized READMEs. File and Link Fix.
2013-10-16 05:14:30 +02:00
contrib: verifybinaries: allow multisig verification This commit adds the functionality necessary to transition from doing binary verification on the basis of a single signature to requiring a minimum threshold of trusted signatures. A signature can appear as "good" from GPG output, but it may not come from an identity the user trusts. We call these "good, untrusted" signatures. We report bad signatures but do not necessarily fail in their presence, since a bad signature might coexist with enough good, trusted signatures to fulfill our criteria. If "--import-keys" is enabled, we will prompt the user to optionally try to retrieve unknown keys. Marking them as trusted locally is a WIP, but keys which are retrieved successfully and appear on the builder-keys list will immediately count as being useful towards fulfilling the threshold. Logging is improved and an option to output JSON that summarizes the whole sum signature and binary verification processes has been added. Co-authored-by: Russ Yanofsky <russ@yanofsky.org> Co-authored-by: willcl-ark <will8clark@gmail.com>
2021-09-17 00:33:20 +02:00
First, you have to figure out which public keys to recognize. Browse the [list of frequent
builder-keys](https://github.com/bitcoin-core/guix.sigs/tree/main/builder-keys) and
decide which of these keys you would like to trust. For each key you want to trust, you
must obtain that key for your local GPG installation.
Prettify some /Contrib READMEs SYN Remove Dead Readme-Qt Links.
2013-10-22 02:00:10 +02:00
contrib: verifybinaries: allow multisig verification This commit adds the functionality necessary to transition from doing binary verification on the basis of a single signature to requiring a minimum threshold of trusted signatures. A signature can appear as "good" from GPG output, but it may not come from an identity the user trusts. We call these "good, untrusted" signatures. We report bad signatures but do not necessarily fail in their presence, since a bad signature might coexist with enough good, trusted signatures to fulfill our criteria. If "--import-keys" is enabled, we will prompt the user to optionally try to retrieve unknown keys. Marking them as trusted locally is a WIP, but keys which are retrieved successfully and appear on the builder-keys list will immediately count as being useful towards fulfilling the threshold. Logging is improved and an option to output JSON that summarizes the whole sum signature and binary verification processes has been added. Co-authored-by: Russ Yanofsky <russ@yanofsky.org> Co-authored-by: willcl-ark <will8clark@gmail.com>
2021-09-17 00:33:20 +02:00
You can obtain these keys by
- through a browser using a key server (e.g. keyserver.ubuntu.com),
- manually using the `gpg --keyserver <url> --recv-keys <key>` command, or
contrib: docs fix --import-keys flag on verify.py
2023-06-08 22:26:09 +02:00
- you can run the packaged `verify.py --import-keys ...` script to
contrib: verifybinaries: allow multisig verification This commit adds the functionality necessary to transition from doing binary verification on the basis of a single signature to requiring a minimum threshold of trusted signatures. A signature can appear as "good" from GPG output, but it may not come from an identity the user trusts. We call these "good, untrusted" signatures. We report bad signatures but do not necessarily fail in their presence, since a bad signature might coexist with enough good, trusted signatures to fulfill our criteria. If "--import-keys" is enabled, we will prompt the user to optionally try to retrieve unknown keys. Marking them as trusted locally is a WIP, but keys which are retrieved successfully and appear on the builder-keys list will immediately count as being useful towards fulfilling the threshold. Logging is improved and an option to output JSON that summarizes the whole sum signature and binary verification processes has been added. Co-authored-by: Russ Yanofsky <russ@yanofsky.org> Co-authored-by: willcl-ark <will8clark@gmail.com>
2021-09-17 00:33:20 +02:00
have it automatically retrieve unrecognized keys.
[contrib] Remove reference to sf and add doc to verify.sh
2016-04-15 12:18:12 +02:00
contrib: verifybinaries: allow multisig verification This commit adds the functionality necessary to transition from doing binary verification on the basis of a single signature to requiring a minimum threshold of trusted signatures. A signature can appear as "good" from GPG output, but it may not come from an identity the user trusts. We call these "good, untrusted" signatures. We report bad signatures but do not necessarily fail in their presence, since a bad signature might coexist with enough good, trusted signatures to fulfill our criteria. If "--import-keys" is enabled, we will prompt the user to optionally try to retrieve unknown keys. Marking them as trusted locally is a WIP, but keys which are retrieved successfully and appear on the builder-keys list will immediately count as being useful towards fulfilling the threshold. Logging is improved and an option to output JSON that summarizes the whole sum signature and binary verification processes has been added. Co-authored-by: Russ Yanofsky <russ@yanofsky.org> Co-authored-by: willcl-ark <will8clark@gmail.com>
2021-09-17 00:33:20 +02:00
#### Usage
[contrib] Remove reference to sf and add doc to verify.sh
2016-04-15 12:18:12 +02:00
contrib: verifybinaries: allow multisig verification This commit adds the functionality necessary to transition from doing binary verification on the basis of a single signature to requiring a minimum threshold of trusted signatures. A signature can appear as "good" from GPG output, but it may not come from an identity the user trusts. We call these "good, untrusted" signatures. We report bad signatures but do not necessarily fail in their presence, since a bad signature might coexist with enough good, trusted signatures to fulfill our criteria. If "--import-keys" is enabled, we will prompt the user to optionally try to retrieve unknown keys. Marking them as trusted locally is a WIP, but keys which are retrieved successfully and appear on the builder-keys list will immediately count as being useful towards fulfilling the threshold. Logging is improved and an option to output JSON that summarizes the whole sum signature and binary verification processes has been added. Co-authored-by: Russ Yanofsky <russ@yanofsky.org> Co-authored-by: willcl-ark <will8clark@gmail.com>
2021-09-17 00:33:20 +02:00
This script attempts to download the checksum file (`SHA256SUMS`) and corresponding
signature file `SHA256SUMS.asc` from https://bitcoincore.org and https://bitcoin.org.
It first checks if the checksum file is valid based upon a plurality of signatures, and
then downloads the release files specified in the checksum file, and checks if the
hashes of the release files are as expected.
If we encounter pubkeys in the signature file that we do not recognize, the script
can prompt the user as to whether they'd like to download the pubkeys. To enable
this behavior, use the `--import-keys` flag.
The script returns 0 if everything passes the checks. It returns 1 if either the
signature check or the hash check doesn't pass. An exit code of >2 indicates an error.
See the `Config` object for various options.
#### Examples
Validate releases with default settings:
```sh
contrib: move verify scripts to verify-binaries
2023-04-09 12:38:22 +02:00
./contrib/verify-binaries/verify.py pub 22.0
contrib: fixup verifybinaries example docs Followup to #27358, fixing up the example command docs.
2023-04-09 12:33:41 +02:00
./contrib/verify-binaries/verify.py pub 22.0-rc3
contrib: verifybinaries: allow multisig verification This commit adds the functionality necessary to transition from doing binary verification on the basis of a single signature to requiring a minimum threshold of trusted signatures. A signature can appear as "good" from GPG output, but it may not come from an identity the user trusts. We call these "good, untrusted" signatures. We report bad signatures but do not necessarily fail in their presence, since a bad signature might coexist with enough good, trusted signatures to fulfill our criteria. If "--import-keys" is enabled, we will prompt the user to optionally try to retrieve unknown keys. Marking them as trusted locally is a WIP, but keys which are retrieved successfully and appear on the builder-keys list will immediately count as being useful towards fulfilling the threshold. Logging is improved and an option to output JSON that summarizes the whole sum signature and binary verification processes has been added. Co-authored-by: Russ Yanofsky <russ@yanofsky.org> Co-authored-by: willcl-ark <will8clark@gmail.com>
2021-09-17 00:33:20 +02:00
```
Get JSON output and don't prompt for user input (no auto key import):
```sh
contrib: move verify scripts to verify-binaries
2023-04-09 12:38:22 +02:00
./contrib/verify-binaries/verify.py --json pub 22.0-x86
contrib: Fixup verify-binaries OS platform parsing Parse platform strings with "-" or '.' correctly such as "linux-gnu" or "x86_64-linux-gnu.tar.gz" to download the matching files or file. String partition() is used to tolerate more dashes. Update `VERSION_EXAMPLE` with a new string parsed correctly now. Fix "-aarch64" interpreted as a release candidate due to sub-string "rc", causing all downloads to fail. Now "rc" must immediately follow first "-" to indicate an [-rc] string. Local variables `version_rc`, `version_os` renamed to `rc`, `platform`. If "-rcN" is specified, `platform` is reassigned to remove the '-rcN'. Changes are useful to only download one bitcoin core binary on slow connections. Making `verify.py pub` more intuitive, robust, and versatile. Closes #30145 When user types a platform string not found in any filename lets help and say the platform closest to what they typed in a `f"No files matched the platform specified. Did you mean: {closest_match}"` log. Improves UX when unaware how we name our files. Uses the difflib Python built-in which was already imported elsewhere. Update test.py to test single file verification verify-binaries/verify.py can accept an entire filename filter for its "-platform" parameter now so let us test that it succeeds and downloads and verifies only one file. `verify.py pub 22.0-x86_64-linux-gnu.tar.gz` should get and verify only the requested binary. It is placed before the existing <version> wide verification as it is a faster test and possibly easier to break. Update doc with examples now possible after bugfix Add example to show release candidates now work with "-platform" strings containing "-" and string provided can be from the middle of filename: `./contrib/verify-binaries/verify.py --json pub 23.0-rc5-linux-gnu` Change example 5 to not match example 3. New examples to show platform can now be provided specifically enough to download only a single binary down to its file extension: `./contrib/verify-binaries/verify.py pub 25.2-x86_64-linux` `./contrib/verify-binaries/verify.py pub 24.1-rc1-darwin` `./contrib/verify-binaries/verify.py pub 27.0-win64-setup.exe` This is the most common use if not verifying all files so users see it as the first example for "only download the binaries for a certain architecture and/or platform". Downloading one file is intuitively what most will think this meant and this change delivers on that expectation. Co-authored-by: stickies-v
2024-05-23 05:37:31 +02:00
./contrib/verify-binaries/verify.py --json pub 23.0-rc5-linux-gnu
contrib: verifybinaries: allow multisig verification This commit adds the functionality necessary to transition from doing binary verification on the basis of a single signature to requiring a minimum threshold of trusted signatures. A signature can appear as "good" from GPG output, but it may not come from an identity the user trusts. We call these "good, untrusted" signatures. We report bad signatures but do not necessarily fail in their presence, since a bad signature might coexist with enough good, trusted signatures to fulfill our criteria. If "--import-keys" is enabled, we will prompt the user to optionally try to retrieve unknown keys. Marking them as trusted locally is a WIP, but keys which are retrieved successfully and appear on the builder-keys list will immediately count as being useful towards fulfilling the threshold. Logging is improved and an option to output JSON that summarizes the whole sum signature and binary verification processes has been added. Co-authored-by: Russ Yanofsky <russ@yanofsky.org> Co-authored-by: willcl-ark <will8clark@gmail.com>
2021-09-17 00:33:20 +02:00
```
verifybinaries: README cleanups - Use correct name for verify.py - Add usage examples for verifybinaries bin - Document proper use of new cleanup option - Fixup broken example
2023-04-04 23:09:42 +02:00
Rely only on local GPG state and manually specified keys, while requiring a
threshold of at least 10 trusted signatures:
[contrib] Remove reference to sf and add doc to verify.sh
2016-04-15 12:18:12 +02:00
```sh
contrib: move verify scripts to verify-binaries
2023-04-09 12:38:22 +02:00
./contrib/verify-binaries/verify.py \
contrib: verifybinaries: allow multisig verification This commit adds the functionality necessary to transition from doing binary verification on the basis of a single signature to requiring a minimum threshold of trusted signatures. A signature can appear as "good" from GPG output, but it may not come from an identity the user trusts. We call these "good, untrusted" signatures. We report bad signatures but do not necessarily fail in their presence, since a bad signature might coexist with enough good, trusted signatures to fulfill our criteria. If "--import-keys" is enabled, we will prompt the user to optionally try to retrieve unknown keys. Marking them as trusted locally is a WIP, but keys which are retrieved successfully and appear on the builder-keys list will immediately count as being useful towards fulfilling the threshold. Logging is improved and an option to output JSON that summarizes the whole sum signature and binary verification processes has been added. Co-authored-by: Russ Yanofsky <russ@yanofsky.org> Co-authored-by: willcl-ark <will8clark@gmail.com>
2021-09-17 00:33:20 +02:00
--trusted-keys 74E2DEF5D77260B98BC19438099BAD163C70FBFA,9D3CC86A72F8494342EA5FD10A41BDC3F4FAFF1C \
contrib: Fixup verify-binaries OS platform parsing Parse platform strings with "-" or '.' correctly such as "linux-gnu" or "x86_64-linux-gnu.tar.gz" to download the matching files or file. String partition() is used to tolerate more dashes. Update `VERSION_EXAMPLE` with a new string parsed correctly now. Fix "-aarch64" interpreted as a release candidate due to sub-string "rc", causing all downloads to fail. Now "rc" must immediately follow first "-" to indicate an [-rc] string. Local variables `version_rc`, `version_os` renamed to `rc`, `platform`. If "-rcN" is specified, `platform` is reassigned to remove the '-rcN'. Changes are useful to only download one bitcoin core binary on slow connections. Making `verify.py pub` more intuitive, robust, and versatile. Closes #30145 When user types a platform string not found in any filename lets help and say the platform closest to what they typed in a `f"No files matched the platform specified. Did you mean: {closest_match}"` log. Improves UX when unaware how we name our files. Uses the difflib Python built-in which was already imported elsewhere. Update test.py to test single file verification verify-binaries/verify.py can accept an entire filename filter for its "-platform" parameter now so let us test that it succeeds and downloads and verifies only one file. `verify.py pub 22.0-x86_64-linux-gnu.tar.gz` should get and verify only the requested binary. It is placed before the existing <version> wide verification as it is a faster test and possibly easier to break. Update doc with examples now possible after bugfix Add example to show release candidates now work with "-platform" strings containing "-" and string provided can be from the middle of filename: `./contrib/verify-binaries/verify.py --json pub 23.0-rc5-linux-gnu` Change example 5 to not match example 3. New examples to show platform can now be provided specifically enough to download only a single binary down to its file extension: `./contrib/verify-binaries/verify.py pub 25.2-x86_64-linux` `./contrib/verify-binaries/verify.py pub 24.1-rc1-darwin` `./contrib/verify-binaries/verify.py pub 27.0-win64-setup.exe` This is the most common use if not verifying all files so users see it as the first example for "only download the binaries for a certain architecture and/or platform". Downloading one file is intuitively what most will think this meant and this change delivers on that expectation. Co-authored-by: stickies-v
2024-05-23 05:37:31 +02:00
--min-good-sigs 10 pub 22.0-linux
[contrib] Remove reference to sf and add doc to verify.sh
2016-04-15 12:18:12 +02:00
```
[contrib] verifybinaries: Keep downloads by default
2016-08-21 21:37:21 +02:00
contrib: Fixup verify-binaries OS platform parsing Parse platform strings with "-" or '.' correctly such as "linux-gnu" or "x86_64-linux-gnu.tar.gz" to download the matching files or file. String partition() is used to tolerate more dashes. Update `VERSION_EXAMPLE` with a new string parsed correctly now. Fix "-aarch64" interpreted as a release candidate due to sub-string "rc", causing all downloads to fail. Now "rc" must immediately follow first "-" to indicate an [-rc] string. Local variables `version_rc`, `version_os` renamed to `rc`, `platform`. If "-rcN" is specified, `platform` is reassigned to remove the '-rcN'. Changes are useful to only download one bitcoin core binary on slow connections. Making `verify.py pub` more intuitive, robust, and versatile. Closes #30145 When user types a platform string not found in any filename lets help and say the platform closest to what they typed in a `f"No files matched the platform specified. Did you mean: {closest_match}"` log. Improves UX when unaware how we name our files. Uses the difflib Python built-in which was already imported elsewhere. Update test.py to test single file verification verify-binaries/verify.py can accept an entire filename filter for its "-platform" parameter now so let us test that it succeeds and downloads and verifies only one file. `verify.py pub 22.0-x86_64-linux-gnu.tar.gz` should get and verify only the requested binary. It is placed before the existing <version> wide verification as it is a faster test and possibly easier to break. Update doc with examples now possible after bugfix Add example to show release candidates now work with "-platform" strings containing "-" and string provided can be from the middle of filename: `./contrib/verify-binaries/verify.py --json pub 23.0-rc5-linux-gnu` Change example 5 to not match example 3. New examples to show platform can now be provided specifically enough to download only a single binary down to its file extension: `./contrib/verify-binaries/verify.py pub 25.2-x86_64-linux` `./contrib/verify-binaries/verify.py pub 24.1-rc1-darwin` `./contrib/verify-binaries/verify.py pub 27.0-win64-setup.exe` This is the most common use if not verifying all files so users see it as the first example for "only download the binaries for a certain architecture and/or platform". Downloading one file is intuitively what most will think this meant and this change delivers on that expectation. Co-authored-by: stickies-v
2024-05-23 05:37:31 +02:00
If you only want to download the binaries for a certain architecture and/or platform, add the corresponding suffix, e.g.:
contrib/verifybinaries: allow filtering by platform Downloading all the binaries of all platforms can take quite long, especially for slow connections, which may deter people from using this script and, therefore, to disregard security altogether. This change introduces the new possibility of specifying the platform along with the version number, so that only the binaries that contain the platform name are downloaded.
2017-04-25 11:40:09 +02:00
```sh
contrib: Fixup verify-binaries OS platform parsing Parse platform strings with "-" or '.' correctly such as "linux-gnu" or "x86_64-linux-gnu.tar.gz" to download the matching files or file. String partition() is used to tolerate more dashes. Update `VERSION_EXAMPLE` with a new string parsed correctly now. Fix "-aarch64" interpreted as a release candidate due to sub-string "rc", causing all downloads to fail. Now "rc" must immediately follow first "-" to indicate an [-rc] string. Local variables `version_rc`, `version_os` renamed to `rc`, `platform`. If "-rcN" is specified, `platform` is reassigned to remove the '-rcN'. Changes are useful to only download one bitcoin core binary on slow connections. Making `verify.py pub` more intuitive, robust, and versatile. Closes #30145 When user types a platform string not found in any filename lets help and say the platform closest to what they typed in a `f"No files matched the platform specified. Did you mean: {closest_match}"` log. Improves UX when unaware how we name our files. Uses the difflib Python built-in which was already imported elsewhere. Update test.py to test single file verification verify-binaries/verify.py can accept an entire filename filter for its "-platform" parameter now so let us test that it succeeds and downloads and verifies only one file. `verify.py pub 22.0-x86_64-linux-gnu.tar.gz` should get and verify only the requested binary. It is placed before the existing <version> wide verification as it is a faster test and possibly easier to break. Update doc with examples now possible after bugfix Add example to show release candidates now work with "-platform" strings containing "-" and string provided can be from the middle of filename: `./contrib/verify-binaries/verify.py --json pub 23.0-rc5-linux-gnu` Change example 5 to not match example 3. New examples to show platform can now be provided specifically enough to download only a single binary down to its file extension: `./contrib/verify-binaries/verify.py pub 25.2-x86_64-linux` `./contrib/verify-binaries/verify.py pub 24.1-rc1-darwin` `./contrib/verify-binaries/verify.py pub 27.0-win64-setup.exe` This is the most common use if not verifying all files so users see it as the first example for "only download the binaries for a certain architecture and/or platform". Downloading one file is intuitively what most will think this meant and this change delivers on that expectation. Co-authored-by: stickies-v
2024-05-23 05:37:31 +02:00
./contrib/verify-binaries/verify.py pub 25.2-x86_64-linux
./contrib/verify-binaries/verify.py pub 24.1-rc1-darwin
./contrib/verify-binaries/verify.py pub 27.0-win64-setup.exe
contrib/verifybinaries: allow filtering by platform Downloading all the binaries of all platforms can take quite long, especially for slow connections, which may deter people from using this script and, therefore, to disregard security altogether. This change introduces the new possibility of specifying the platform along with the version number, so that only the binaries that contain the platform name are downloaded.
2017-04-25 11:40:09 +02:00
```
verifybinaries: README cleanups - Use correct name for verify.py - Add usage examples for verifybinaries bin - Document proper use of new cleanup option - Fixup broken example
2023-04-04 23:09:42 +02:00
If you do not want to keep the downloaded binaries, specify the cleanup option.
[contrib] verifybinaries: Keep downloads by default
2016-08-21 21:37:21 +02:00
```sh
contrib: move verify scripts to verify-binaries
2023-04-09 12:38:22 +02:00
./contrib/verify-binaries/verify.py pub --cleanup 22.0
verifybinaries: README cleanups - Use correct name for verify.py - Add usage examples for verifybinaries bin - Document proper use of new cleanup option - Fixup broken example
2023-04-04 23:09:42 +02:00
```
Use the bin subcommand to verify all files listed in a local checksum file
```sh
contrib: move verify scripts to verify-binaries
2023-04-09 12:38:22 +02:00
./contrib/verify-binaries/verify.py bin SHA256SUMS
verifybinaries: README cleanups - Use correct name for verify.py - Add usage examples for verifybinaries bin - Document proper use of new cleanup option - Fixup broken example
2023-04-04 23:09:42 +02:00
```
Verify only a subset of the files listed in a local checksum file
```sh
contrib: move verify scripts to verify-binaries
2023-04-09 12:38:22 +02:00
./contrib/verify-binaries/verify.py bin ~/Downloads/SHA256SUMS \
verifybinaries: README cleanups - Use correct name for verify.py - Add usage examples for verifybinaries bin - Document proper use of new cleanup option - Fixup broken example
2023-04-04 23:09:42 +02:00
~/Downloads/bitcoin-24.0.1-x86_64-linux-gnu.tar.gz \
~/Downloads/bitcoin-24.0.1-arm-linux-gnueabihf.tar.gz
[contrib] verifybinaries: Keep downloads by default
2016-08-21 21:37:21 +02:00
```
Reference in New Issue Copy Permalink