[mrxiaozhuox]

Description

The current Hash check in the code will directly cause the program to throw an error. When using Search, if there is even one Hash check failure, no information can be displayed.

I have fixed this issue and retained the error throw in the Install section. However, I don't think it's necessary to make the program fail to run specifically because of this issue.

The possible useful solutions I have thought of, which I can modify if you are willing to accept, are:

1. Automatically ignore all packages with Hash check failures.
2. Give users the right to choose, informing them that the content does not match, but they can still install it.

[mrxiaozhuox]

It seems that directly adding a dirty field in the pkgs is not a good idea, so we can only wrap a layer of status or directly filter out the data that failed the hash verification.

[mrxiaozhuox]

or add a new flag to decide how to control hash check failed.

[mrxiaozhuox]

I pushed a new update to fix the issue without affecting the structure.

• for nupm search: hidden hash check failed package.
• for nupm install: throw hash check failed error.

[amtoine]

hopefully superseded by #111

[mrxiaozhuox]

hopefully superseded by #111

I believe there is a substantial difference between these two PRs. Your PR seems to fix the Hash operation, but what this PR does is: if there is a Hash check failure, it does not affect the results of nupm search, because a hash check failure would directly terminate the entire program, and if there is one failure in the registry, none of the search results can be displayed.

Do you intend to fix this issue in your PR?

Thank you.

[amtoine]

aah okok my bad.

well yeah, maybe once the fix lands, we can think about what should happen if a hash fails 😉

[kubouch]

Thanks for the PR, sorry for the late reply.

I think the logic could be simplified: Inside search-package, don't throw an error at all, but just add a new column “hash_mismatch” (instead of “dirty”, I think it's more descriptive) with true/false depending on whether the hash failed or not. Then, applications that want to throw an error (nupm publish, nupm install) can do so afterward, and nupm search can just filter it out. nupm search could return the search result, but if there are some mismatches, it could print a warning, for example.

[kubouch]

Again, sorry for the late reply, I don't have much time to consistently work on nupm.

There are still test failures. There are some hash mismatches and nupm publish seems to be looking for the hash-mismatch column in the test registry package file of spam_script: https://github.com/nushell/nupm/blob/main/tests/packages/registry/spam_script.nuon . So I think these need to be addressed, but otherwise the PR seems good.

[kubouch]

Btw, you might experience some type-related errors due to the last Nushell update. I fixed those on the main branch.

[mrxiaozhuox]

Again, sorry for the late reply, I don't have much time to consistently work on nupm.

There are still test failures. There are some hash mismatches and nupm publish seems to be looking for the hash-mismatch column in the test registry package file of spam_script: https://github.com/nushell/nupm/blob/main/tests/packages/registry/spam_script.nuon . So I think these need to be addressed, but otherwise the PR seems good.

do I need edit tests/nu.nu or just https://github.com/nushell/nupm/blob/main/tests/packages/registry/spam_script.nuon this file?

[kubouch]

I haven't looked closely, but the hash-mismatch shouldn't be a part of the registry package files (like the spam_script.nuon). So nupm publish (and other relevant commands) should be modified to not require this column in those files.

[mrxiaozhuox]

Only this part used search-package, but only take type field, so I don't know why test will check hash-mismatch:

nupm/nupm/publish.nu

Lines 50 to 61 in e9f39ea

	let res = search-package $pkg.name --registry $reg_path --exact-match
	| first # there will be only one result because we passed local path
	| get pkgs
	| sort-by-version
	if ($res | is-empty) {
	throw-error ($"Cannot guess package type because pacakge"
	+ $" ($pkg.name) was not found in registry ($registry). Specify"
	+ " the type manually with --git or --local flag.")
	}
	$res | last | get type

Maybe because this?

nupm/nupm/utils/registry.nu

Line 11 in 335a577

export const REG_PKG_COLS = [ name version path type info hash_mismatch ]

did test will check this var?

[mrxiaozhuox]

I haven't looked closely, but the hash-mismatch shouldn't be a part of the registry package files (like the spam_script.nuon). So nupm publish (and other relevant commands) should be modified to not require this column in those files.

I found a cols check at here:

nupm/nupm/publish.nu

Lines 234 to 240 in e9f39ea

	let exp_cols = $REG_PKG_COLS
	if (($pkg_content | is-not-empty)
	and ($pkg_content | columns) != $exp_cols) {
	throw-error ($"Unexpected columns of package file ($pkg_path)."
	+ $" Got ($pkg_content | columns), needs ($exp_cols).")
	}

I want delete hash-mismatch at REG_PKG_COLS, because I think this only a temp field. how do u think?

[kubouch]

I want delete hash-mismatch at REG_PKG_COLS, because I think this only a temp field. how do u think?

Yeah, this sounds reasonable.

[mrxiaozhuox]

I want delete hash-mismatch at REG_PKG_COLS, because I think this only a temp field. how do u think?

Yeah, this sounds reasonable.

I deleted hash_mismatch field.

[kubouch]

Good, there are still some test failures, can you fix those?

[mrxiaozhuox]

Good, there are still some test failures, can you fix those?

sorry for late, I don't know how to fix this error, look's like test package and registry's hash not match.

[kubouch]

You can update the hash in the registry to match the package hash.

[mrxiaozhuox]

You can update the hash in the registry to match the package hash.

OMG, I fixed it.

I checked the MD5-related content many times and finally found that it was actually a conditional statement error. 😢

[kubouch]

That happens :D Thanks!