Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debian 10 repository #54979

Closed
enterdv opened this issue Oct 12, 2019 · 13 comments
Closed

Debian 10 repository #54979

enterdv opened this issue Oct 12, 2019 · 13 comments
Assignees
Labels
Bug broken, incorrect, or confusing behavior P2 Priority 2 severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around
Milestone

Comments

@enterdv
Copy link

enterdv commented Oct 12, 2019

Description of Issue

Repository doesn't have latest directory

http://repo.saltstack.com/py3/debian/10/amd64/

@seandhaynes
Copy link

seandhaynes commented Oct 12, 2019

To add to the above, when following Salt installation docs for Debian 10 (Buster) here: https://repo.saltstack.com/#debian

The below links 404:
http://repo.saltstack.com/py3/debian/10/amd64/latest/
http://repo.saltstack.com/py3/debian/10/amd64/2019.2
http://repo.saltstack.com/py3/debian/10/amd64/2019.2.1

As not only is latest missing, but 2019.2.1 is located within archive. There are also no other salt versions present under amd64.

I'm assuming this is due to the security vulnerabilities found in 2019.2.1, and 2019.2.2 not being packaged for Debian 10 yet. If so, it may be worth updating the documentation above to reflect that, or stating that Debian packages for Buster aren't currently available.

@arizvisa
Copy link
Contributor

arizvisa commented Oct 14, 2019

Lol? Security vulnerabilities!? Try #54755 or https://groups.google.com/forum/#!topic/salt-users/pDn_NU1g8cg. Referenced performance issue is likely #54941.

Salt's latest CVE was from earlier in the year.

(edited to link to performance regression)

@seandhaynes
Copy link

Lol? Security vulnerabilities!? Try #54755 or https://groups.google.com/forum/#!topic/salt-users/pDn_NU1g8cg. Referenced performance issue is likely #54941.

Salt's latest CVE was from earlier in the year.

(edited to link to performance regression)

My apologies, I misread the warning on this page: https://repo.saltstack.com/

Which actually highlights several stability issues (rather than security issues) here: https://docs.saltstack.com/en/latest/topics/releases/2019.2.1.html

Regardless, I don't understand what value your comment adds here? I apologise for misreading the issue with 2019.2.1, but I added the details above to try and help highlight a problem. Your comment isn't constructive and doesn't encourage people to try and help.

@dmurphy18
Copy link
Contributor

@seandhaynes The delay with 2019.2.2 was initially due to a performance issue (pillar rebuilt on each command, hence seconds instead of miiliseconds) which is now fixed however a problem was found with git.latest over the weekend, the fix is being tested today. Hopefully a refreshed 2019.2.2 should be released soon. And may I draw your attention to the Warning message on the repo landing page.

@enterdv The correct path for the Debian 10 Salt 2019.2.1 is http://repo.saltstack.com/py3/debian/10/amd64/archive/2019.2.1

@garethgreenaway garethgreenaway added Bug broken, incorrect, or confusing behavior severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around P2 Priority 2 and removed needs-triage labels Oct 14, 2019
@garethgreenaway garethgreenaway added this to the Approved milestone Oct 14, 2019
@arizvisa
Copy link
Contributor

You need to be careful with mentioning something is a security vuln. There's a huge process that's involved if something is a security vulnerability. Google CVE and look at the number of results to see how many of us actually monitor and schedule updates based on this.

If there was a security vuln and 2019.2.1 was removed, think about everybody that is in a sensitive environment that will now need to dig through commits to figure out what is needed to be merged. (I almost did which is why I had to dig up explicitly why salt removed those binaries other than the pip issue).

Casually mentioning something is a security vuln w/o proof of tracking, and claiming that it resulted in a number of binaries being removed is definitely spreading FUD.

@seandhaynes
Copy link

seandhaynes commented Oct 15, 2019

Thanks very much for the clarity, @dmurphy18 . I'll keep an eye on the repository for 2019.2.2.

@arizvisa Right... and "Lol? Security vulnerabilities!?" really cleared the situation up, did it?

I don't doubt that my comment mislead you, but I already apologised for that, and still see no justification for how you responded. A simple "What issues are you referring to?" would have been fine, and I would still have apologised.

Also, a Github comment shouldn't be your source of truth for a security vulnerability, especially not a CVE. Considering changing your internal Salt packaging off the back of a Github issue less than 48 hours old (at the time of my comment) and a single comment with no information on a vulnerability is irresponsible from an Administration point of you, and lazy from a perspective of security research.

Anyway, apologies once again if you really do feel that spreading FUD was my intention. It wasn't anything more than an honest mistake whilst trying to help.

@arizvisa
Copy link
Contributor

In all actuality, github commits and comments are sources of truth for security vulnerabilities. Egor Homakov is a pretty good example of dropping vulns in comments. LKML is an even better example of devers either mis-identifying them, mis-classifying them, or even silently fixing them. Vulns start in code and in bugtrackers. Hell. Shellshock was a bug report before a talented rh guy discovered that it had more implications than just a simple side-effect.

That "simple" github issue was part of a major release. 2019.2.1. As I had updated my fuzzers to this version. I had literally just gone through slamming through fixing bugs that I had encountered and then discovered that the problems were more widespread and not just simple fixes. Reading a comment where someone implies that there was a security vulnerability between 2019.2.0 and 2019.2.1 and it is being silenced/hidden is cause for research. I don't believe the saltstack developers are shady like that and actually care about some of us.

But, just because I laughed and dropped some links to "clear the situation up", doesn't mean I didn't accept your apology. In all actuality, you're the one that's misinterpreting an acryonym. In response to your being offended at someone laughing over the internet and then providing links to correct some misinformation. I simply responded with an answer to your question by providing a situation on why it's important to be cautious when talking about silently fixed vulns. Don't take offense when someone answers a question that you apparently wanted answered.

@arizvisa
Copy link
Contributor

@enterdv, please close this ticket if your question was answered and issue resolved. Thx!

@enterdv
Copy link
Author

enterdv commented Oct 16, 2019

@arizvisa Now I see only archive repo. In documentation https://repo.saltstack.com/#debian works one repo to Minor release.
Do you think that issue resolved?

@arizvisa
Copy link
Contributor

Yeah. I personally do as the issue was about the debian 10 repo, which multiple people responded to with reasons why it's missing (or has been archived).

The correct path for the latest binary packages was given by dmurphy18, repo.saltstack.com only works as a minor release as documented in their mailing list, saltstack has apologized for their bunk release, and we're stuck waiting for v2019.2.2 or updating from source instead of packages (which despite it being a pain for us, we should be doing honestly anyways)

But really, it is up to you. If you believe there's something else that can fix the debian repo being empty other than their suggested minor release (in /archive), waiting for a new release, or installing/maintaining from source.

@johnkeates
Copy link

2019.2.2 is out! Any known timeframe on release-to-repo?

@enterdv
Copy link
Author

enterdv commented Oct 24, 2019

@enterdv enterdv closed this as completed Oct 24, 2019
@johnkeates
Copy link

Very cool, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug broken, incorrect, or confusing behavior P2 Priority 2 severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around
Projects
None yet
Development

No branches or pull requests

6 participants