Update after move to new GitHub org

.github/workflows/build.yml

@@ -82,7 +82,7 @@ jobs:
       - name: Checkout library
         uses: actions/checkout@v4
         with:
-          repository: "hyperledger/indy-blssignatures-rs"
+          repository: "hyperledger-indy/indy-blssignatures-rs"
           path: "build"
 
       - name: Build

CODE_OF_CONDUCT.md

@@ -1,4 +1,4 @@
-# [Hyperledger Code of Conduct](https://wiki.hyperledger.org/community/hyperledger-project-code-of-conduct)
+# [LF Decentralized Trust Code of Conduct](https://lf-decentralized-trust.github.io/governance/governing-documents/code-of-conduct/)
 
 The Hyperledger Foundation is a collaborative project at The Linux Foundation.
 It is an open-source and open community project where participants choose to

README.md

@@ -7,8 +7,8 @@ This package implements a version of the BLS signature scheme. The implementatio
 This package is NOT recommended for new projects. It would be preferable to use a BLS signatures implementation based on the IETF draft, on a curve with a stronger security estimation (such as BLS12-381).
 
 [BLS signatures specification at the IETF]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-05
-[Hyperledger Indy BLS Signatures Rust]: https://github.com/hyperledger/indy-blssignatures-rs
-[Hyperledger Indy Node]: https://github.com/hyperledger/indy-node
+[Hyperledger Indy BLS Signatures Rust]: https://github.com/hyperledger-indy/indy-blssignatures-rs
+[Hyperledger Indy Node]: https://github.com/hyperledger-indy/indy-node
 
 ## Installation
 
@@ -26,7 +26,7 @@ The primary build dependency is the Rust crate: [Hyperledger Indy BLS Signatures
 
 ## Contributing
 
-Pull requests are welcome! Please read our [contributions guide](https://github.com/hyperledger/indy-bls-wrapper-python/blob/main/CONTRIBUTING.md) and submit your PRs. We enforce [developer certificate of origin](https://developercertificate.org/) (DCO) commit signing. See guidance [here](https://github.com/apps/dco).
+Pull requests are welcome! Please read our [contributions guide](https://github.com/hyperledger-indy/indy-bls-wrapper-python/blob/main/CONTRIBUTING.md) and submit your PRs. We enforce [developer certificate of origin](https://developercertificate.org/) (DCO) commit signing. See guidance [here](https://github.com/apps/dco).
 
 We also welcome issues submitted about problems you encounter in using `indy_bls`.
 
@@ -36,4 +36,4 @@ This code is based on the original Ursa Python wrapper contributed by Cam Parra.
 
 ## License
 
-Licensed under the Apache License, Version 2.0. ([LICENSE-APACHE](https://github.com/hyperledger/indy-bls-wrapper-python/blob/main/LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0).
+Licensed under the Apache License, Version 2.0. ([LICENSE-APACHE](https://github.com/hyperledger-indy/indy-bls-wrapper-python/blob/main/LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0).

SECURITY.md

@@ -10,13 +10,13 @@ the discoverer.
 
 To report a security bug email a description of the flaw and any related
 information (e.g. reproduction steps, version)
-to [security@lists.hyperledger.org](mailto:security@lists.hyperledger.org).
+to [security@lists.lfdecentralizedtrust.org](mailto:security@lists.lfdecentralizedtrust.org).
 
 Security Bug Handling Process
 
 1. The person discovering the issue, the reporter, reports the vulnerability
    privately to
-   [security@lists.hyperledger.org](mailto:security@lists.hyperledger.org).
+   [security@lists.lfdecentralizedtrust.org](mailto:security@lists.lfdecentralizedtrust.org).
 2. Messages that do not relate to the reporting or managing of an undisclosed
    security vulnerability in Hyperledger software are ignored and no further
    action is required.
@@ -41,13 +41,13 @@ to include in the report is a matter of judgment. Generally, reports should
 contain enough information to enable people to assess the risk associated with
 the vulnerability for their system and no more. Steps to reproduce the
 vulnerability are not normally included.
-11. The project team commits the fix. No reference should be made to the commit
+1.  The project team commits the fix. No reference should be made to the commit
     being related to a security vulnerability.
-12. The project team creates a release that includes the fix.
-13. The project team announces the release. The release announcement should be
+2.  The project team creates a release that includes the fix.
+3.  The project team announces the release. The release announcement should be
     sent to the usual mailing lists (typically the project's user list, dev
     list, announce list, and the Hyperledger announce list).
-14. The project team announces the vulnerability. The vulnerability announcement
+4.  The project team announces the vulnerability. The vulnerability announcement
     should be sent after the release announcement to the following destinations:
   1. The same destinations as the release announcement.
   2. The vulnerability reporter.
@@ -70,5 +70,5 @@ public.
 Information may be shared with domain experts (e.g. colleagues at your employer)
 at the discretion of the project's security team providing that it is made clear
 that the information is not for public disclosure and
-that [security@lists.hyperledger.org](mailto:security@lists.hyperledger.org)
+that [security@lists.lfdecentralizedtrust.org](mailto:security@lists.lfdecentralizedtrust.org)
 org must be copied on any communication regarding the vulnerability.

setup.py

@@ -9,7 +9,7 @@
     version="0.1.0",
     long_description=long_description,
     long_description_content_type="text/markdown",
-    url="https://github.com/hyperledger/indy-bls-wrapper-python",
+    url="https://github.com/hyperledger-indy/indy-bls-wrapper-python",
     classifiers=[
         "Programming Language :: Python :: 3",
         "License :: OSI Approved :: Apache Software License",