-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Comments
To add to the above, when following Salt installation docs for Debian 10 (Buster) here: https://repo.saltstack.com/#debian The below links 404: 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. |
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. |
@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 |
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. |
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. |
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. |
@enterdv, please close this ticket if your question was answered and issue resolved. Thx! |
@arizvisa Now I see only archive repo. In documentation https://repo.saltstack.com/#debian works one repo to Minor release. |
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. |
2019.2.2 is out! Any known timeframe on release-to-repo? |
Very cool, thanks! |
Description of Issue
Repository doesn't have latest directory
http://repo.saltstack.com/py3/debian/10/amd64/
The text was updated successfully, but these errors were encountered: