electric-coin-company / kotlin-bip39 Goto Github PK

For a Gradle dependency:

1. Update the dependency version in the root gradle.properties
2. Update the dependency locks
   1. For Gradle plugins: ./gradlew dependencies --write-locks
   2. For Gradle dependencies: ./gradlew resolveAll --write-locks
3. Verify no unexpected entries appear in the lockfiles. A supply chain attack could occur during this stage. The lockfile narrows the supply chain attack window to this very moment (as opposed to every time a build occurs).
4. Are there any new APIs or possible migrations for this dependency?
   1. This should be relatively minor for our library
   2. There are some new regex APIs
   3. min/max are back on collections
   4. https://kotlinlang.org/docs/whatsnew17.html

See https://github.com/zcash/zcash-android-wallet-sdk and https://github.com/zcash/secant-android-wallet for examples of what build conventions would look like.

Specific conventions would be:

• Kotlin multiplatform
• Android
• ...

As a followup to #23, configure tests to also run on GitHub Actions.

Is your feature request related to a problem? Please describe.

Our default branch names are not consistent for our Android projects.

Describe the solution you'd like

Align branch names for consistency, changing the default branch to main.

required changes include:

• Setting the GitHub setting for the default branch
• Verifying that branch protection/security rules are still in place and that deployment secrets are only available to the branch called main
• Updating the deploy-snapshot.yml and deploy-release.yml to run on the main branch instead of master

https://github.com/actions/cache/releases/tag/v3.0.4

We need to prepare for a future release by:

• Bumping the version to 1.0.3
• Updating the Maven properties
• Updating the changelog
• Adding documentation on deployment
• Testing out automated deployment

Is your feature request related to a problem? Please describe.

In order to be able to release updates to the library, we should have automated deployments.

Describe the solution you'd like

Create an automated deployment with GitHub Actions, similar to the deployment configured in the Zcash Android SDK.

Steps that need to be completed:

1. Add markdown documentation on how CI works in this repo
2. Add documentation on how to consume snapshot deployments
3. Add secrets to GitHub for the main branch deployments. The necessary secrets are defined here: https://github.com/zcash/kotlin-bip39/blob/main/.github/workflows/deploy-release.yml
4. Test the deployments

We need to explicitly add the path to the setup action.

Verify that 6 and 9 words work as expected, add tests to confirm the behavior and then merge the change made here:

JarmoKukkola@3f5100a

This should come after #18.

Is your feature request related to a problem? Please describe.

It is annoying to keep GitHub Actions dependencies updated.

Describe the solution you'd like

Although dependabot does not support Gradle yet, it does support GitHub Actions. So we can configure dependabot to help with this.

Is your feature request related to a problem? Please describe.

To reduce the risk of software supply chain issues, we should enable dependency locking.

Although the published library itself doesn't depend on third party libraries, the Gradle build does rely on some plug-ins and the tests rely on some third party libraries.

Describe the solution you'd like

Enable dependency locking for the build scripts, build-conventions, as well as add a new dependency locking convention similar to https://github.com/zcash/secant-android-wallet/blob/main/build-convention/src/main/kotlin/zcash.dependency-conventions.gradle.kts

This depends on #20 to be implemented first.

For a Gradle dependency:

1. Update the dependency version in the root gradle.properties
2. Update the dependency locks

1. Are there any new APIs or possible migrations for this dependency?

1. Are there any new APIs or possible migrations for this dependency?
   1. https://github.com/actions/cache/releases/tag/v3.0.3

This is a followup for after 1.0.3 is released, basically this is just a version bump for now.

The artifact is published in Maven Central, so the readme can be updated to reflect this. There are two changes:

• Replace jcenter with maven central
• Bump the version in the readme, since maven central only has a slightly newer version.

Running detekt points out:

kotlin-bip39/lib/src/jvmMain/kotlin/cash/z/ecc/android/bip39/Mnemonics.kt:85:53: This implementation of Iterator does not correctly implement the next() method as it doesn't throw a NoSuchElementException when no elements remain in the Iterator. [IteratorNotThrowingNoSuchElementException]

Note that the detekt baseline will suppress this warning. When implementing this change, be sure to update the detekt baseline file to remove this suppression.

Update Contributing Guidelines "Commit Messages" section to reflect the changes on iOS SDK

Is your feature request related to a problem? Please describe.

We have a number of ECC team members who are not familiar with IntelliJ and Kotlin. To help them be able to build this project from source, we should have easy to follow setup instructions.

Describe the solution you'd like

Something similar to https://github.com/zcash/secant-android-wallet/blob/main/docs/Setup.md

1. Update the dependency version in the root gradle.properties
2. Update the dependency locks
   1. For Gradle plugins: ./gradlew dependencies --write-locks
3. Verify no unexpected entries appear in the lockfiles. A supply chain attack could occur during this stage. The lockfile narrows the supply chain attack window to this very moment (as opposed to every time a build occurs)
4. Are there any new APIs or possible migrations for this dependency?
   1. Note there are some new rules introduced with this update that will require formatting changes or new @Suppress statements.

Create a basic GitHub action script to validate the gradle wrapper, compile the library, run ktlint, and detekt.

#24 is a followup issue to run the tests. Note that tests aren't being configured in this issue, because running the Android tests on CI can be complex. If we migrate to Multiplatform, then running those tests would be easier.

Is your feature request related to a problem? Please describe.

Gradle toolchains only support Adoptium JDKs, however we have been recommending Zulu. This means different developers may have inconsistent JVMs. Although they should be compatible, it would be great to eliminate this variability in builds.

Describe the solution you'd like

Now that Adoptium publishes a Mac ARM JDK 11, we can remove using Zulu.

• Update readme to remove references to Azul
• Update GitHub Actions to use Adoptium

1. Are there any new APIs or possible migrations for this dependency?
   1. https://github.com/actions/setup-java/releases/tag/v3.3.0

jcenter is deprecated, so migrate our build scripts to get dependencies from MavenCentral.

For consistency with our other Gradle and Kotlin projects, convert our build scripts to kts.

This should likely be implemented after #15 and #16 since those have some syntax changes for build scripts.

Migrate to using a toml-based version catalog for dependencies.

For a Gradle dependency:

1. Update the dependency version in the root gradle.properties
2. Update the dependency locks
   1. For Gradle dependencies: ./gradlew resolveAll --write-locks
3. Verify no unexpected entries appear in the lockfiles. A supply chain attack could occur during this stage. The lockfile narrows the supply chain attack window to this very moment (as opposed to every time a build occurs).
4. Are there any new APIs or possible migrations for this dependency?
   1. Minor update
   2. https://github.com/Kotlin/kotlinx.coroutines/releases/tag/1.6.3

Is your feature request related to a problem? Please describe.

Developers have a hard time understanding how well the tests cover the library.

Describe the solution you'd like

Introduce code coverage, most likely with the JetBrains Kover Gradle plugin.

Alternatives you've considered

We can manually apply Jacoco to generate coverage, although Kover will be more robust.

Add contributing Guidelines present on the other projects like ZcashLightClientKit or secant-ios-wallet

Since there's no demo app, this line should be deleted from the review checklist:

Run the app: Did you run the demo app and try the changes?

Is your feature request related to a problem? Please describe.

Although we don't really include dependencies in the library, having a dependencyUpdates task to identify Gradle, Kotlin, and plugin updates would be helpful.

Describe the solution you'd like

https://github.com/ben-manes/gradle-versions-plugin

Describe the issue

The binaries generated from the GitHub Actions are empty when attached to the build.

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

1. Run the staging deployment
2. Look at the output e.g. https://github.com/zcash/kotlin-bip39/actions/runs/2501530576

Expected behaviour

The output should have the JAR files.

Actual behavior + errors

The attached binaries are 22 bytes, e.g. they are empty.

When Mnemonics is first touched, it performs an initialization of SecureRandom which is known to be slow.

While documenting this could be helpful, it doesn't give clients using this library a lot of options to work around it. That's because Mnemonics is an object, so initialization is effectively a JVM static initializer when means it runs as soon as something touches the object.

Possible alternative implementations:

• Defer SecureRandom initialization until it is needed, giving clients better control over timing
• Convert Mnemonics to a class, so that initialization happens during construction which allows clients better control over timing of the initialization
• Create a companion object initializer. This could be a suspend function, allowing secure random injection into a private constructor for Mnemonics
• ... There may be other options to consider as well

Is your feature request related to a problem? Please describe.

Some Kotlin idols idioms can make it more likely to introduce accidental API changes or leakage of internals via the public API.

Describe the solution you'd like

https://kotlinlang.org/docs/whatsnew14.html#explicit-api-mode-for-library-authors

Adding this to the ktlintFormat Gradle task should solve it:

jvmArgs("--add-opens", "java.base/java.lang=ALL-UNNAMED")

1. Are there any new APIs or possible migrations for this dependency?
   1. https://github.com/actions/upload-artifact/releases/tag/v3.1.0

Is your feature request related to a problem? Please describe.

When doing multiple included builds with build-conventions, things can break when modules or conventions have the same name.

This will be a problem if trying to use an included build for both bip-39 and the Android SDK.

Describe the solution you'd like

Rename the build-conventions folder to have a namespace.

To prevent compiler warnings from being introduced, they should be configured to be considered build errors. To implement this, add a property to gradle.properties so that this option can be turned off during local development if desired.

This should be implemented after #20

See https://github.com/zcash/secant-android-wallet for an example of how this was implemented.

1. Visit the GitHub New Issue template chooser
2. Look at the description for the new feature template

Migrate to the Kotlin Multiplatform Gradle plugin, but without any actual multiplatform implementation.

Is your feature request related to a problem? Please describe.

When Gradle plugins are applied, they can define their own Maven repositories. This could allow dependencies to come from sources that we don't trust.

Describe the solution you'd like

In settings.gradle.kts, configure

repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)

This is likely blocked until this is resolved: https://youtrack.jetbrains.com/issue/KT-52383/Kotlin-Multiplatform-Gradle-Plugin-Unable-to-disable-project-rep

Hello,

jcenter repo is shutting down. Do you have any plans to migrate?

As a library user, I'd like to clearly understand how uppercase and lowercase letters are handled. This should be included in the readme, confirmed with a unit test, and future-proof for other languages. In other words, whatever approach that is taken should also work for every common language used for bip39 word lists.

From a clean checkout:

./gradlew clean
./gradlew test

Results in the stack trace identified here
kotest/kotest#1600

See the https://github.com/zcash/zcash-android-wallet-sdk or https://github.com/zcash/secant-android-wallet for examples of the templates we'd use for bugs, features, and dependency updates.

There's a duplicate copy of the Gradle wrapper under lib/. We just need the copies of these in the repo root. To resolve this, delete the following paths:

• lib/gradle
• lib/gradlew
• lib/gradlew.bat

Our deployment jobs in GitHub actions are missing environment: deployment so they aren't able to read the secrets necessary for deployment.