This only applies when multiple XML nodes are present with the same name. E.g. multiple description or releaseNoteLink elements with different xml:lang's specified.
Also generate a warning if an language has to be interpreted implicitly when there is no xml:lang explicitly specified and there are multiple node items.
This also allows embedded release notes to be plain text using sparkle:format="plain-text" attribute.
Also, Catalyst apps only support plain text release notes (compared to before where release notes weren't supported for Catalyst apps).
Also log out the download failure when a delta update fails to download (such as a 404 error for example).
Additionally, add a check to make sure that top-level appcast items cannot be delta update items.
Normally when a major upgrade is skipped, subsequent updates for that major release are skipped. This element however allows publishing updates that ignore the user skipping the major version before a specific sub-release.
This allows marking all updates below a specific version as informational only.
A new element (sparkle:belowVersion) was introduced this over a new attribute for sparkle:version due to compatibility reasons.
We should recommend using sparkle:version and sparkle:shortVersionString elements inside the appcast item instead of inside the enclosure for consistency.
Delta updates do not need to specify sparkle:version, and can inherit the top level element. This clears up some confusion and reduces duplication (and reduces error proneness / saves me work when testing delta / info-only features).
This is also consistent with informational updates. Regardless whether you want to make an update informational only or not, the sparkle:version stays in the same top-level place.
This is a backwards compatible change. Very old versions of Sparkle (possibly up to a decade or more ago) have supported specifying sparkle:version as a top level item. Winsparkle supports it as well because it's needed for info-only updates.
This is only changing what we recommend / standardize. The attribute variants are still usable.
External tools relying on Sparkle's feed format may have to adapt to this standardization (they have always needed to support info-only updates with a missing enclosure which apps do leverage anyway).
I updated generate_appcast to prefer the element variants and updated the tool so it understands them (this was a bug).
This version indicates the version that was first marked critical. So versions below this specified version will treat the update as critical while versions >= the specified version will not.
Also move sparkle:criticalUpdate to root level element instead of it being a tag. The tagged version is now deprecated and doesn't support the version field.
This gets more complicated, since binaries can be just code-signed, or
use both code signing and DSA keys, or be rotating keys for one or the
other.
The code signing test cases emulate certificate rotation by changing
the "identifier" for the bundle; the script used to sign each bundle
(with ad hoc signing) is included to support future expansion of
testing.
The actual tests here are the same as pre-validation; things only get
complicated when validating with code signing. The setup's a little
more involved though, since we need a supposedly-downloaded bundle to
do anything.
Also test invalid signatures, which are not always the same as absent
signatures.
* Adds a test case for the "criticalUpdate" appcast tag (not as a XCTest but simply as an assert inside the test app, because I was lazy and am working on an older Xcode version that does not support the currently needed swift version for the XCTest in SUAppcastTest.swift).
* Tests the "criticalUpdate" appcast tag, using the proper XCTest swift class. I haven't tested this, though, due to the lack of the needed Xcode version.
* Test case for Appcast now checks all 4 items for the correct "criticalUpdate" state.
* Adds a test case for the "criticalUpdate" appcast tag (not as a XCTest but simply as an assert inside the test app, because I was lazy and am working on an older Xcode version that does not support the currently needed swift version for the XCTest in SUAppcastTest.swift). (reverted from commit 3ce1c9790b)
Interactive package installs now need to be opted into (foo.sparkle_interactive.pkg or foo.sparkle_interactive.mpkg)
The website documentation may need to be updated later, and this should be noted as an important point in the change log.
Add the capability to set a decryption password for updating with an
encrypted dmg file.
This enables the the ability to update using an encrypted disk image without having to prompt the user for a password. This is useful when access to the application binaries is only available via distribution or from a location in which authentication is required. This can help prevent an attacker from having unwanted access to application binaries for reverse engineering.
This assists with a defense in depth approach to security.
* All supported compression formats are now tested including dmg, which
has a license agreement included
* The hash of the extracted directory is now checked, which encompasses
every file's existence, its contents, and its permissions.
* Re-written using Swift
There's a zipped up sample app in the unit test target. This gets unzipped to
a temporary folder and there are three versions of it: the original which is not
code signed at all, another with a valid code signature, and a third which
has had one of its resources removed after code signing to make it invalid.