-
Notifications
You must be signed in to change notification settings - Fork 79
Comparing changes
Open a pull request
base repository: passepartoutvpn/openssl-apple
base: master
head repository: cossacklabs/openssl-apple
compare: cossacklabs
Commits on May 8, 2020
-
Don't symlink macOS framework if not building it
If only iOS frameworks are being build, we should not try to create macOS framework by symlinking stuff. Do this only if the framework actually requested by the arch/target selection.
Configuration menu - View commit details
-
Copy full SHA for 60551b4 - Browse repository at this point
Copy the full SHA 60551b4View commit details -
Lower SDK minimums to iOS 8.0 and macOS 10.9
These are the versions currently supported by Themis. While we can definitely bump them up to iOS 10.0 and macOS 10.14 somewhere in 2020, let's keep them matching Themis requirements for now.
Configuration menu - View commit details
-
Copy full SHA for 444d952 - Browse repository at this point
Copy the full SHA 444d952View commit details -
Update Info.plist metadata with CossackLabs branding
Change the bundle ID to something related to us so that we're not infringing on "org.openssl" namespace (used by the original project), and have the binary we build clearly associated with us. Similarly, we are going to offer OpenSSL 1.0.2u, hence update the marketing version of the bundle to reflect that. Also update the default version in the build script so that we can use it directly.
Configuration menu - View commit details
-
Copy full SHA for c954f18 - Browse repository at this point
Copy the full SHA c954f18View commit details -
Use targets CossackLabs cares about by default
Update the default architecture/target list to include only the architectures we care about: - iOS Simulator i386 - iOS Simulator x86_64 - iOS ARM64 - iOS ARMv7s - iOS ARMv7 - macOS x86_64 Note that we need i386 and ARMv7 iOS Simulator builds due to the minimum SDK version requirements we use. macOS has been x86_64-only for a while. Currently we do not support tvOS and watchOS, so don't build frameworks for those targets by default. The full set of available targets has been updated to include all that for future reference.
Configuration menu - View commit details
-
Copy full SHA for 27e6a21 - Browse repository at this point
Copy the full SHA 27e6a21View commit details -
Verify OpenSSL tarball checksums
It's not nice to just download whatever source code from the Internet and build a cryptography library from that. At least verify that the checksum of the file is the expected one. The checksums are retrieved via a trusted Web browser from a trusted network from the official Web site. We check that the file we download is the one we should expect, just in case openssl.org gets MITMed.
Configuration menu - View commit details
-
Copy full SHA for 641757d - Browse repository at this point
Copy the full SHA 641757dView commit details -
Binary project specifications for Carthage
Host the specs so that Carthage projects can depend on this library. Note that we still have to respect Carthage versioning policy.
Configuration menu - View commit details
-
Copy full SHA for d5a33a6 - Browse repository at this point
Copy the full SHA d5a33a6View commit details
Commits on May 10, 2020
-
Configuration menu - View commit details
-
Copy full SHA for fde0916 - Browse repository at this point
Copy the full SHA fde0916View commit details
Commits on Jul 21, 2020
-
Merge branch 'master' into cossacklabs
Resolved conflicts in favor of master with its more generic approach to defining minimum SDK versions.
Configuration menu - View commit details
-
Copy full SHA for b7c970e - Browse repository at this point
Copy the full SHA b7c970eView commit details
Commits on Jul 28, 2020
-
* Maintainer Makefile Add a Makefile to make releasing new versions easier. It encapsulates common tasks for preparing a release. With this Makefile, the release flow should be something like this: 1. Update OpenSSL version and checksum in build-libssl.sh Update minimum and target API versions as necessary too. 2. Run "make". Wait. 3. Commit, tag, push changes. 4. Create GitHub release, attach framework packages from "output". Currently we support only Carthage publishing. Carthage packages are published when the tag and commit are pushed. Later CocoaPods will be added into the flow. This will require additional validation step *after* the tag is published and GitHub release is created, followed by manual podspec publishing. Carthage binary project specs have a new naming, more consistent with platform names used by OpenSSL build scripts. However, we still keep the old specs around because they may still be needed on the "cossacklabs" branch. They can be removed only after the release is made, when we are sure that all users of the experimental branches have migrated away. * Move modifications into Makefile Newer version of the build-libssl.sh script allow more configurability so we do not have to modify it to achieve what we want. Roll back our changes and move them into the Makefile instead, changing relevant defaults using the commmand-line options.
Configuration menu - View commit details
-
Copy full SHA for 37bcb04 - Browse repository at this point
Copy the full SHA 37bcb04View commit details
Commits on Jul 30, 2020
-
As of now, OpenSSL 1.1.1g is the latest stable version of OpenSSL.
Configuration menu - View commit details
-
Copy full SHA for 200ffc0 - Browse repository at this point
Copy the full SHA 200ffc0View commit details
Commits on Aug 3, 2020
-
CocoaPods spec: CLOpenSSL (#3)
Support publishing our OpenSSL build on CocoaPods. Now running "make specs" will also generate "cocoapods/CLOpenSSL.podspec" which can be uploaded to CocoaPods repositories. The spec does not actually build OpenSSL on the user machine. Instead, it downloads prebuilt frameworks (the same as used by Carthage). This results in considerable savings of the installation time. The framework binaries are currently hosted as GitHub releases. Not checking them into the repository also gives some savings (or rather, will give over time). Since the spec still clones *this* repository, it will be possible to build OpenSSL from source on developers' machines, if needed. Only dynamic frameworks are supported with CocoaPods. There is an option to include static frameworks, but that does not work out of the box and is very inconvenient for us to support. Note that at the moment there is no "v1.0.221" tag in this repository so the produced Podspec will not pass linting. It can be properly and fully linted only after the tag is published. (That's how Cocoapods works.)
Configuration menu - View commit details
-
Copy full SHA for 045d3d8 - Browse repository at this point
Copy the full SHA 045d3d8View commit details
Commits on Aug 6, 2020
-
Configuration menu - View commit details
-
Copy full SHA for 6bbc5dc - Browse repository at this point
Copy the full SHA 6bbc5dcView commit details -
Since we've made the first proper release, let's document the process so that it goes quicker next time.
Configuration menu - View commit details
-
Copy full SHA for 214f628 - Browse repository at this point
Copy the full SHA 214f628View commit details
Commits on Aug 7, 2020
-
I have missed this architecture from the default list. It is important for more security featuress of iOS [1], let's add it. The architecture has been available for a while, and it looks like latest devices are going to require it. [1]: https://developer.apple.com/documentation/security/preparing_your_app_to_work_with_pointer_authentication Co-Authored-By: vixentael <vixentael@users.noreply.github.com> Co-authored-by: vixentael <vixentael@users.noreply.github.com>
Configuration menu - View commit details
-
Copy full SHA for c05395c - Browse repository at this point
Copy the full SHA c05395cView commit details
Commits on Aug 10, 2020
-
Use original OpenSSL version for static frameworks (#7)
...but use the semversified version for dynamic frameworks. That is, for OpenSSL 1.1.1g static frameworks will have "1.1.1g" in their Info.plist, dynamic frameworks will have "1.1.107" in their Info.plist, and the tag on the repository will be "v1.1.107". This is becase we need to keep the version in static frameworks distributed for Carthage (static ones) so that certain dependency checkers are happy. We need to modify the version in dynamic frameworks as they are going to be included into the app bundle and we need to make the App Store happy. We need to have the tag semver-valid too because Carthage needs to be still happy. But what if there is CocoaPods project which also uses a dependency checked which will be thrown off guard with a weird OpenSSL version? Well, the thing is, you as a maintainer are not entitled to be happy. All package managers apparently want you to suffer until you submit to their demands, so does the App Store where all the apps are going to be submitted. Ultimately, you do want that shiny money, right? If you didn't, you'd be working for a different ecosystem. IDK, making desktop Linux great again, or Plan 9, or Raku. There is a moment when a person breaks. This is it for me. If someone demands the version to be a picture, or a dance, or a poem, then the version will be just that. If this commit causes you trouble -- whoever is reading this in "git blame" -- because you don't understand why the versioning is so weird, why there is this change that causes merge conflicts, why your customers are not happy because a weird version of dependency of a dependency prevents the app from validating. If any of this happens, please know that I'm deeply sorry for this, but it's your turn. I hope you can make the world a better place, as I hope that no one will have to touch this magic and it will continue working long past anyone remembers why. Until it breaks, that is. It's 3:10 AM and I probably should not be submitting this change, waiting for a cool down, but... whatever vOv
Configuration menu - View commit details
-
Copy full SHA for 891134d - Browse repository at this point
Copy the full SHA 891134dView commit details
Commits on Sep 28, 2020
-
Drop historical Carthage specs (#8)
Now all production users are using new, consistently named spec files. Drop old files which are not actively used by any of our projects.
Configuration menu - View commit details
-
Copy full SHA for aac0a14 - Browse repository at this point
Copy the full SHA aac0a14View commit details
Commits on Oct 26, 2020
-
* Apple Silicon support Add architecture configuration for OpenSSL based on changes suggested by Sasmito [1]. Since we're interested only in macOS and iOS, add only those simulators, cross-compiled for arm64. This only lets the compiler to compile something as support for arm64 is not complete in OpenSSL [2]. For example, you can see that we disable inline assembly, so the code might actually run slower. It's not much of an issue right now though since there is no arm64 hardware yet on the public market. [1]: balthisar#6 [2]: openssl/openssl#12254 However, don't add the new arm64 architecture to the list of default architectures and targets to compile OpenSSL for (DEFAULTARCHS and DEFAULTTARGETS in "build-libssl.h"). This is because arm64 is currently supported only in Xcode betas, it's not available yet for the stable releases. Those wishing to experiment with arm64 architecture will have to specify appropriate targets manually on the command line. Suggested-by: Sasmito Adibowo <adib@basil-salad.com> * Differentiate iOS Simulator headers New arm64 architecture for iOS Simulator is conflicting with arm64 architecture for the real iOS devices. Though the architecture is the same, the target is not. A different SDK is used to build arm64 for Apple Silicon devices, and it's not compatible in the strict sense. OpenSSL currently has per-architecture headers with platform-specific details. Make sure that iOS ones don't conflict with iOS Simulator by making iOS use "openssl_ios_arm64.h" and iOS Simulator will be using "openssl_ios_sim_arm64.h" * Add platform-specific headers for arm64 Introduce conditionals to check for and use arm64 on macOS and for the iOS Simulator builds.
Configuration menu - View commit details
-
Copy full SHA for 4e7bf92 - Browse repository at this point
Copy the full SHA 4e7bf92View commit details -
Build arm64 slices if requested (#10)
* Bump minimum platform versions of iOS and macOS Bring them in line with the current recommendations of Xcode 12 and current requirements of Themis which is the main consumer of CLOpenSSL at the moment. * Enable building arm64 if requested Add arm64 to the list of architectures to build when requested by the user, this can be done by setting APPLE_SILICON_SUPPORT environment or Make variable to "yes", for example: make APPLE_SILICON_SUPPORT=yes We intend to provide arm64 builds in the default package, but until it is available in stable Xcode releases, arm64 capability will be under the feature gate to avoid breaking stable Xcode builds. Currently using APPLE_SILICON_SUPPORT requires Xcode 12+ beta to be active. Also note that currently only the macOS build is enabled. It is possible to build arm64 for iOS Simulator, but it's currently not possible to package the results into the same fat binary along with the arm64 slice for the actual iOS devices. This issue will be solved later. It seems that using XCFrameworks should allow mixing targets the way we need it.
Configuration menu - View commit details
-
Copy full SHA for 62ccf2e - Browse repository at this point
Copy the full SHA 62ccf2eView commit details -
Extra package version digits (#11)
Teenage mutant ninja turtles ...sorry. Occasionally we need to publish the same OpenSSL version several times, such as when the version did not really change but Apple platforms did. Normally you increment the "patch version" for this, or some dedicated "package version", but we don't have that luxury with OpenSSL. We must keep the version strictly semver, and all the digits are already taken with OpenSSL version, even with some extra on top. The current latest version of OpenSSL is 1.1.1h. However, semver does not allow letters so we transform that into 1.1.108: 1.1.1h => 1.1.(1 * 100) + ('h' - 'a' + 1) => 1.1.108 In the similar vein, add yet another 'package version' part to this whole mess: 1.1.1h-1 => 1.1.((1 * 100) + ('h' - 'a' + 1)) * 100 + 1 => 1.1.10801 It's not the prettiest solution but... doin' what I can with what I got. This approach is semver-compatible, pleasing our fruit company overlords. The resulting version ordering is useful. Since the 1.1.107 has been the only release so far, migration to 1.1.10701 is smooth. The transformation is reversible and unambiguous (well, let's hope we won't need to release more than 100 versions of the same OpenSSL). The source of truth for CLOpenSSL is the PACKAGE_VERSION variable in the Makefile. Bump it to release a new package version. Reset it to "1" when updating OpenSSL version. Note that the tag names are using the same approach because they are significant to Carthage and CocoaPods.
Configuration menu - View commit details
-
Copy full SHA for 0afb091 - Browse repository at this point
Copy the full SHA 0afb091View commit details -
Temporarily exclude arm64 for iOS Simulator (#12)
As it was noted before [1], we are currently unable to support arm64 for both iOS and iOS simulators. Disable the arm64 slice for iOS Simulator to let the podspec be linted properly. This requires Xcode 12 to compile and use. [1]: cossacklabs#9
Configuration menu - View commit details
-
Copy full SHA for eb48f8a - Browse repository at this point
Copy the full SHA eb48f8aView commit details
Commits on Oct 27, 2020
-
Use static frameworks for CocoaPods (#13)
Okay, let's try this again. Previously we have experimented with 'static framworks' -- regular frameworks but with static libraries in them instead of dynamic ones. It turns out that a special CocoaPods option seems to make them work after all. Convert CLOpenSSL into a static framework for CocoaPods too, like we already do for Carthage.
Configuration menu - View commit details
-
Copy full SHA for d21e3b7 - Browse repository at this point
Copy the full SHA d21e3b7View commit details -
Fix minimum OS version setup (#14)
Make sure to export the MIN_IOS_SDK and MIN_OSX_SDK variables from the makefile as they are needed in "scripts/update-specs.sh" to properly fill in the minimum version requirements in generated CocoaPods spec. Otherwise we only pass them to the OpenSSL build scripts and end up with the spec requesting more broad minimum versions than the range actually supported by the binaries. Instead of exporting the variables to specific script invocations, just make sure that Make exports them to all tools that it launches. That way it's harder to forget to add them for some script.
Configuration menu - View commit details
-
Copy full SHA for 6d9f6cd - Browse repository at this point
Copy the full SHA 6d9f6cdView commit details -
Update to OpenSSL 1.1.1h (#15)
There is nothing notable about this release, just some bugfix [1]. [1]: https://www.openssl.org/news/changelog.html#openssl-111
Configuration menu - View commit details
-
Copy full SHA for 9b3000c - Browse repository at this point
Copy the full SHA 9b3000cView commit details -
Make podspec summary short (#16)
CocoaPods issues a warning if the summary is long, it expects it to be tweet-sized (under 140 characters). Well, split the current summary into a short part and move OpenSSL description into "description". Now it should be possible to lint the spec without "--allow-warnings".
Configuration menu - View commit details
-
Copy full SHA for 3622f35 - Browse repository at this point
Copy the full SHA 3622f35View commit details -
Configuration menu - View commit details
-
Copy full SHA for 8ba2cea - Browse repository at this point
Copy the full SHA 8ba2ceaView commit details
Commits on Nov 22, 2020
-
Merge branch 'master' into cossacklabs
Sync our branch with upstream updates. The updates add Apple Silicon support (with hardware acceleration), XCFrameworks, and other updates. The following commits on our branch are now obsolete: - 4e7bf92 Note that due to the changes our Makefile build system is currently broken. The following commits will fix this. This one only gets the merge correctly.
Configuration menu - View commit details
-
Copy full SHA for 12b15ba - Browse repository at this point
Copy the full SHA 12b15baView commit details -
Configuration menu - View commit details
-
Copy full SHA for 6a8e199 - Browse repository at this point
Copy the full SHA 6a8e199View commit details -
Remove arm64e slice; return dyn linking for CocoaPods (#18)
* Automatically enable Apple Silicon support Since Xcode 12.2 (stable) is out, Apple Silicon support can be enabled automatically there. Check the version of the command-line tools and set APPLE_SILICON_SUPPORT value automatically if possible. After a while, once Xcode 12.0.1 and earlier are not longer supported and widely used, this variable can be removed completely. Right now it won't be really necessary to set it explicitly, unless you want something strange. * Revert "Use static frameworks for CocoaPods (#13)" This reverts commit d21e3b7. We can't just migrate CLOpenSSL to static frameworks as that requires all upstream dependencies to migrate to static frameworks too, and that breaks builds left, right, and center. Instead, we have figured out what has been breaking dynamic linkage with CocoaPods, and now we're coming back to using dynamic linkage. If static versions of CLOpenSSL are published, they will be published in a separate podspec. * Drop arm64e to work around CocoaPods issues arm64e builds are included to test the pointer authentication feature of iOS devices. We have to include it in binary CLOpenSSL builds so that upstream users of CLOpenSSL might enable it themselves for testing. However, inclusion of this architecture slice causes issues with CocoaPods handling of vendored binary frameworks. arm64e builds include a certain linker command -- LC_DYLD_CHAINED_FIXUPS (0x80000034) -- which confuses CocoaPods' detector of dynamic binaries, making it believe that the vendored framework in a static one, not dynamic. This in turn causes issues when using CLOpenSSL as CocoaPods refuses to link "static" binary without "static_framework = true". This is a know issue in CocoaPods, stemming from the missing features in Homebrew's Mach-O parser [1][2]. [1]: Homebrew/brew#7857 [2]: Homebrew/ruby-macho#261 There is nothing we can do about it right now, other than disable "arm64e" builds for the time being. This does not affect deployment to App Store, but will break dependencies of CLOpenSSL which expect this architecture to be present. The dependencies will have to disable arm64e in their projects, if they have it explicitly enabled. (Considering that CocoaPods packaging of CLOpenSSL was never in good shape, the actual impact of this change should be minimal.) * Set install name during linkage Instead of using "install_name_tool" to fix the LC_ID_DYLIB value of the dylib, pass the "-install_name" parameter to the linker directly. This doesn't change anything in the resulting binary but looks a bit cleaner. * Use ABI-correct install name on macOS On macOS -- contrary to iOS, watchOS, and tvOS -- it is customary for frameworks to provide additional internal structure which helps with binary compatibility. For example, on iOS/watchOS/tvOS a framework typically has flat structure: openssl.framework ├── Headers ├── Info.plist └── openssl while on macOS it's a bit more involved: frameworks/MacOSX/openssl.framework ├── Headers -> Versions/Current/Headers ├── Resources -> Versions/Current/Resources ├── Versions │ ├── A │ └── Current -> A └── openssl -> Versions/Current/openssl Note that the top-level files are actually symlinks to the "Versions/Current" which in turn is a symlink to the "A" version, which actually contains the framework content: openssl.framework/Versions/A ├── Headers ├── Resources │ └── Info.plist └── openssl Currently, the 'install name' of all "openssl" binaries is set to "@rpath/openssl.framework/openssl", which makes the linked binaries remember and use this path when loading OpenSSL. On macOS this will involve two additional symlink resolutions. Another thing here is that if we will need to introduce a different version of OpenSSL framework on macOS, existing applications will still look up the current one, instead of using the A version that they should. Update the install name computation to use @rpath/openssl.framework/openssl for iOS, watchOS, tvOS while using more explicit @rpath/openssl.framework/Versions/A/openssl for macOS. This is how Apple's system frameworks do it. Though they have a pressing issue of supporting multiple possible ABIs and it's not that important in our case, you never know when this turns out to be necessary or whether some weird tool might choke on the symlinks.
Configuration menu - View commit details
-
Copy full SHA for 75b8306 - Browse repository at this point
Copy the full SHA 75b8306View commit details
Commits on Nov 23, 2020
-
Configuration menu - View commit details
-
Copy full SHA for d57682e - Browse repository at this point
Copy the full SHA d57682eView commit details
Commits on Nov 24, 2020
-
Configuration menu - View commit details
-
Copy full SHA for cf2c68b - Browse repository at this point
Copy the full SHA cf2c68bView commit details -
XCFramework support and packaging (#21)
* Drop support for OpenSSL 1.0.x Upstream commit 184673f has removed support for OpenSSL 1.0.x, now the archirectures to build for are specified only via "--targets" option, "--archs" is not supported. Do not set it up and do not pass it to the build script. * Restore removed iOS 10.0 targets Upstream has moved to using iOS 12.0 as the default minimum supported version. With this, several architectures has been removed in commit 2be1214. However, we are still using iOS 10.0 as our minimum supported version and still the removed 32-bit architectures: armv7 and arm7s for iOS devices and i386 for simulators. If they are not included in the binary frameworks, Xcode will complain about missing architecture slices. * Adjust packaging to XCFrameworks Upstream has moved to packaging a single XCFramework with all targets in it. This brings good news as now Apple Silicon will be supported for iOS Simulators, removing the need for some hacks. This also brings bad news because this is a breaking change for CLOpenSSL users. In order to avoid breakage, the packages are renamed. CocoaPods' pod is now named "CLOpenSSL-XCF" and Carthage binary dependencies should be retrieved using the "openssl-{static,dynamic}-xcframework.json" specs. The reason for this is that Carthage users will have to adjust their binary dependencies to download the unified XCFramework instead of two separate frameworks for iOS and macOS. They will also need to adjust their Xcode projects to use "openssl.xcframework" instead of the usual "openssl.framework". While CocoaPods should automatically figure this out, we won't take chances and will make this a flag day for CocoaPods users as well. This is also a breaking change for our build system as the upstream build system now builds iOS (device) and iOS Simulator frameworks separately. This means that there are two "openssl.framework" binaries for iOS and neither is usable with both iOS and iOS Simulator, as it was before. We can't package them as an "iPhone" target to maintain backward compatibility with previous Carthage packaging. Overall, this means that the next release of CLOpenSSL is a flag day for its users. Users of the previous version MUST migrate their builds if they wish to future updates. Otherwise they can continue using 1.1.10802. * Include arm64 slice for iOS Simulators Now that we are building XCFrameworks, we can also include the arm64 slice for iOS Simulator (if Xcode supports Apple Silicon), without getting any errors from linker. It is also not necessary now to exclude this slice from projects generated by CocoaPods. That is, for CLOpenSSL consumers. Upstream library users like Themis might still need the exclusion until they are producing XCFramework-compatible artifacts. However, CLOpenSSL does not need to enforce this exclusion by itself from now on.
Configuration menu - View commit details
-
Copy full SHA for 1a8a267 - Browse repository at this point
Copy the full SHA 1a8a267View commit details
Commits on Dec 15, 2020
-
Configuration menu - View commit details
-
Copy full SHA for 0674511 - Browse repository at this point
Copy the full SHA 0674511View commit details
Commits on Mar 11, 2021
-
Configuration menu - View commit details
-
Copy full SHA for 4b0b616 - Browse repository at this point
Copy the full SHA 4b0b616View commit details
Commits on Apr 26, 2021
-
Configuration menu - View commit details
-
Copy full SHA for 721919c - Browse repository at this point
Copy the full SHA 721919cView commit details -
Configuration menu - View commit details
-
Copy full SHA for 70cbfcf - Browse repository at this point
Copy the full SHA 70cbfcfView commit details
Commits on Apr 27, 2021
-
Merge pull request #22 from julepka/spm-xcf-support
Swift Package Manager support with xcframework
Configuration menu - View commit details
-
Copy full SHA for 5efca9f - Browse repository at this point
Copy the full SHA 5efca9fView commit details -
Configuration menu - View commit details
-
Copy full SHA for 19b79d4 - Browse repository at this point
Copy the full SHA 19b79d4View commit details
Commits on Apr 29, 2021
-
Configuration menu - View commit details
-
Copy full SHA for afd16d4 - Browse repository at this point
Copy the full SHA afd16d4View commit details
Commits on May 6, 2021
-
Configuration menu - View commit details
-
Copy full SHA for 5898308 - Browse repository at this point
Copy the full SHA 5898308View commit details
Commits on Aug 3, 2023
-
Configuration menu - View commit details
-
Copy full SHA for 6c19a16 - Browse repository at this point
Copy the full SHA 6c19a16View commit details -
Configuration menu - View commit details
-
Copy full SHA for 60271d8 - Browse repository at this point
Copy the full SHA 60271d8View commit details
Commits on Sep 6, 2023
-
Configuration menu - View commit details
-
Copy full SHA for 44edb34 - Browse repository at this point
Copy the full SHA 44edb34View commit details -
Configuration menu - View commit details
-
Copy full SHA for 16e3360 - Browse repository at this point
Copy the full SHA 16e3360View commit details
Commits on Sep 7, 2023
-
Configuration menu - View commit details
-
Copy full SHA for a34cfaa - Browse repository at this point
Copy the full SHA a34cfaaView commit details -
Configuration menu - View commit details
-
Copy full SHA for a5ffe8e - Browse repository at this point
Copy the full SHA a5ffe8eView commit details -
Configuration menu - View commit details
-
Copy full SHA for fcab6ae - Browse repository at this point
Copy the full SHA fcab6aeView commit details -
Configuration menu - View commit details
-
Copy full SHA for e937003 - Browse repository at this point
Copy the full SHA e937003View commit details
Commits on Sep 11, 2023
-
Merge pull request #26 from cossacklabs/openssl-1.1.1v
Openssl 1.1.1v + improvements
Configuration menu - View commit details
-
Copy full SHA for f35370a - Browse repository at this point
Copy the full SHA f35370aView commit details
Commits on May 22, 2024
-
Configuration menu - View commit details
-
Copy full SHA for 5357563 - Browse repository at this point
Copy the full SHA 5357563View commit details -
Configuration menu - View commit details
-
Copy full SHA for e1604be - Browse repository at this point
Copy the full SHA e1604beView commit details
There are no files selected for viewing
Uh oh!
There was an error while loading. Please reload this page.