{"id":65710,"date":"2023-04-17T11:23:49","date_gmt":"2023-04-17T03:23:49","guid":{"rendered":"https:\/\/version-2.com.sg\/?p=65710"},"modified":"2024-11-11T15:10:54","modified_gmt":"2024-11-11T07:10:54","slug":"march-2023-whats-new","status":"publish","type":"post","link":"https:\/\/version-2.com\/zh\/2023\/04\/march-2023-whats-new\/","title":{"rendered":"March 2023: What’s New?"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

“What’s New?” is a series of blog posts covering recent changes to Comet in more detail. This article covers the latest changes in Comet Voyager over March 2023.<\/em><\/p>

There were just three Comet software releases during March – two in the 23.3.x Voyager release series, plus one minor patch update 23.2.1 for our quarterly “Leda” release track.<\/p>

We’ve landed a few large and exciting features this March:<\/p>

S3 Object Lock\u200b<\/a><\/h2>

Comet 23.3.1 adds support for Object Lock on S3. This feature allows Comet to “lock” an object inside a S3-compatible bucket, preventing it from being deleted or modified for a fixed period of time.<\/p>

This is a fantastic new capability for Comet and it is a key defense against ransomware. Comet generally requires the capability to add and delete files within your Storage location; deleting files is necessary for applying retention passes, updating index files, and coordinating locking across multiple devices. However, if malware is running on your PC and manages to intercept Comet’s storage credentials, the malware would also be able to delete files, causing much wider havoc.<\/p>

Comet uses S3 “Compliance Mode” to lock individual objects within the storage location. This ensures that there is no way for the object to be deleted for the specified time, not using Comet’s storage credentials, nor even if your administrator S3 keys are leaked or exposed.<\/p>

For a visual overview of the process, please see our usage guide<\/a> and also the simplified explanation<\/a>.<\/p>

This feature is available for Amazon S3, Wasabi, IDrive (excluding Storage Template provisioning), and other S3-compatible providers including Minio-based providers. Please check with your S3-compatible provider’s documentation to see if Object Lock is available.<\/p>

Object Lock is an opt-in feature, both in Comet and with cloud storage providers. It also relies on S3 bucket versioning. These properties generally must be set when the S3 bucket is created for the first time. It is not generally possible to enable Object Lock on an existing S3 bucket. To use Object Lock with an existing S3-based Storage Vault, you would have to create a new S3 bucket with Object Lock enabled; migrate the data; and update Comet’s Storage Vault settings to point to the updated bucket.<\/p>

Comparison to Backblaze B2\u200b<\/a><\/h3>

Regular users of Comet may be aware of the existing “Hide files rather than deleting them” option<\/a> for Backblaze B2. Backblaze B2 supports both a native API and also an S3-compatible layer over the native API. Comet Backup integrates with the native API, so the new S3 Object Lock feature is not available for use with Backblaze B2. However, the existing “Hide files instead of deleting them” option can be used to provide the same protection against ransomware.<\/p>

Codesigning with Azure Key Vault\u200b<\/a><\/h2>

If you are customizing the branding of the Comet Backup desktop app, then we would recommend setting up codesigning certificates. Having a codesigning certificate means that installing Comet Backup proceeds more smoothly through Smartscreen and Antivirus popup warnings on Windows, and through Gatekeeper on macOS.<\/p>

The Windows codesigning programme, “Authenticode”, is currently in a period of disruption as new rules are being put in place. Owing to the high number of events<\/a> where developer codesigning certificate files were leaked<\/a> or lost, new requirements are being enforced from June 1st 2023<\/a> that newly issued codesigning certificates must no longer be stored as plain files on disk, but instead must be stored in a Hardware Security Module (“HSM”) or equivalent isolated device. Comet has long supported Authenticode certificates using either certificate files (“PKCS #12”), or via plug-in HSM devices that are compatible with the “PKCS #11” standard.<\/p>

There are two tiers of Authenticode available. The Extended Validation (“EV”) service performs a deeper level of business-level and legal checks of the target organization before issuing the certificate. The extra vetting comes with a higher purchase cost, but it also results in a higher level of initial reputation for the resulting codesigned .exe<\/code> file. An EV certificate was always required to be stored on an HSM.<\/p>

However, it’s common to install Comet Server on a cloud VM or VPS, where plugging in a USB dongle or smartcard hardware device is not physically possible. This difficulty also discouraged many MSPs from using the higher-quality Extended Validation service. With the impending phaseout of the file-based method for newly issued certificates, neither existing option is suitable, so another option had to be found.<\/p>

Comet 23.3.0 adds support for codesigning using Azure Key Vault<\/a>. This is a cloud service from Microsoft to manage the secure provisioning of security keys and certificates, including for Authenticode codesigning. There are various services and pricing tiers available; in particular, it’s possible to purchase a managed cloud HSM, which meets the new June 1st 2023 Authenticode requirements.<\/p>

<\/p>

At the time of writing, we would recommend GlobalSign<\/a> or TrustZone<\/a> for issuing new Authenticode certificates. There is no carry-over reputation with Authenticode, so replacement certificates can be issued from any provider. These particular providers were prepared early for the new requirements and have a secure vetting process to prove your use of an HSM, such as an Azure Key Vault managed HSM, before issuing your certificate. The private key never leaves the managed cloud HSM device, and Comet Server only uses an Azure application ID to remotely perform the signing steps.<\/p>

Comet Server can perform Authenticode codesigning for Windows, regardless of whether Comet Server is installed on a Windows or Linux host OS. This is achieved by using a cross-platform signing toolchain. To support the new Azure Key Vault feature, we replaced our existing bundled codesigning toolchain from osslsigncode<\/a> with a new jsign<\/a> version. Comet ships these third-party utilities as a courtesy in compliance with their redistribution license.<\/p>

For most existing users of codesigning with a PKCS#12 file-based certificate on disk, there will be no noticeable difference and Comet will continue to work without any configuration changes. However, some users may experience breaking changes:<\/p>