electron/get

bug: the SHASUMS256.txt download is corrupted with custom filename mirror options set

Opened this issue · 2 comments

When downloading from a mirror and specifying a custom filename, the SHASUMS256.txt is always invalid. When the checksum is downloaded in this case

get/src/index.ts

Lines 125 to 138 in 9034cc4

if (
!artifactDetails.artifactName.startsWith('SHASUMS256') &&
!artifactDetails.unsafelyDisableChecksums
) {
const shasumPath = await downloadArtifact({
isGeneric: true,
version: artifactDetails.version,
artifactName: 'SHASUMS256.txt',
force: artifactDetails.force,
downloadOptions: artifactDetails.downloadOptions,
cacheRoot: artifactDetails.cacheRoot,
downloader: artifactDetails.downloader,
mirrorOptions: artifactDetails.mirrorOptions,
});
there are two places where the filename used to build the download url can be overwritten by mirror options and corrupt the resulting SHASUMS256.txt file. One is if the mirrorOptions.customFilename is set and the other is if any of the custom_filename env vars are set:
const file = mirrorVar('customFilename', opts, getArtifactFileName(details));
function mirrorVar(
name: keyof Omit<MirrorOptions, 'resolveAssetURL'>,
options: MirrorOptions,
defaultValue: string,
) {
// Convert camelCase to camel_case for env var reading
const lowerName = name.replace(/([a-z])([A-Z])/g, (_, a, b) => `${a}_${b}`).toLowerCase();
return (
process.env[`NPM_CONFIG_ELECTRON_${lowerName.toUpperCase()}`] ||
process.env[`npm_config_electron_${lowerName}`] ||
process.env[`npm_package_config_electron_${lowerName}`] ||
process.env[`ELECTRON_${lowerName.toUpperCase()}`] ||
options[name] ||
defaultValue
);
}
In either case, the default filename for the checksum passed as 'SHASUMS256.txt' gets chosen last after the custom filename and gets overwritten

Can reproduce by setting the mirror var for electron custom filename and trying to get the electron binary via downloadArtifact(). The checksum will error with Error: Could not parse checksum file at line 1: PK as the SHASUMS256.txt is invalid

Hey, did you find a fix for the issue or is it still pending?
I'm struggling with it as-well

Hi, I believe this issue is still pending, although I think it could have a quick fix. I was forced to work around it by using custom directory structures only, and no custom filenames