Ed, Would you feel better setting aside your winter instead of summer?
We operate an open/transparent organization. Your shell-based mission-critical tasks are trapped inside your shell. Putting them in a CI would do everyone a world of good, so that others can contribute to your enjoyment of summer. I do agree that you are ill-informed. What we're doing here is not ultra-security, as you refer to it. What we are doing is on page 2 of the "Running a server on the Internets 101" book that was published in 1992. And you're right - Jenkins vs. shell is not much better. The new Jiro (on Kubernetes) is. Matt has been doing some digging and I believe has some potential workarounds for yourself, and Markus. Stay tuned. Thanks for understanding, Denis On 2019-08-27 2:26 p.m., Ed Merks wrote: > > Denis, > > Comments below. > > On 27.08.2019 19:27, Denis Roy wrote: >> >> Ed, >> >> I think we're one of the last shops on earth that has SSH shell >> access right into our mission-critical infra. >> > Being able to use vi in my home folder doesn't strike me as treading > into your mission-critical infrastructure, but hey, I'm clearly not > well-informed. I must point out though that like Markus, I provide > numerous services that are also mission critical. But, for the > greater good of ultra-security, of course I'll quickly set aside my > summer and my personal life to address, at my own expense, this latest > pressing security concern inorder to find alternative ways to make > things work nevertheless. > > But wait, I couldn't do a build for days because Mac signing didn't > work. Oh, and suddenly today, out of nowhere: > > [ERROR] The following artifacts could not be downloaded: [ERROR] > osgi.bundle,org.bouncycastle.bcprov,1.61.0.v20190602-1335 [ERROR] > Internal error: java.lang.RuntimeException: Some required artifacts > could not be downloaded. See log output for details. -> [Help 1] My builds > fail again for another reason. In the end though, ulta-security waits for no > person. >> >> Even before 2009 this practice was pure insanity from a data/systems >> security perspective but it was maintained as there were not many >> options. >> > Really? File access permissions are so insanely insecure? So if I > login and delete a file, that's just insane, but when I run my Jenkins > job to delete that file, it's totally secure and the world is safe. I > totally don't get it, but as I said, I'm ill-informed. > >> With Jenkins per Project (JIPP), there's just no reason to leave a >> well-known security faux-pas enabled. It's like putting a credit card >> number on LinkedIn. >> > As I assumed, it's all for the greater good. Much like that "It's so > reassuring that so many people will benefit from that new highway that > will consume your home and property." On that front, I know I always > feel so much more secure when I have to agree to yet another cookie > prompt on a web page. Thanks EU, I feel like my web experience is > totally ultra-cookike-secure now. I just need that highly in-demand > the-make-the-cookie-go-away app. And whenever I do anything around > here where I live now, I have to sign the data security form, that I > can't read, but must sign nevertheless. It totally makes me feel like > my best interests (security) are always the prime concern. > >> As I understand it, there were less than 30 people with full shell >> access. If hundreds of projects don't need it, it's really hard to >> justify. >> > Of course we were given ample opportunity for justification. And of > course trying to justify insanity would just be proof of insanity. So > good for us that there are those who decree that plain insanity is > something to which we must put and end, immediately, during the > summer, when of course no one has anything better to do than migrate > to the new improved ultra-secure non-insane better alternatives: run > Jenkins jobs for hours trying to do accomplish what you could do in > minutes with a shell. >> >> In the end, we're not here to intentionally piss folks off with >> useless dogma -- we're here to help. Part of that mission statement >> is making sure our systems don't suffer a catastrophic >> compromise/data breach. >> > It's feels so much better to be pissed of unintentionally. :-P > > Of course your role is to serve the best interests of the community, > and I feel bad to rag on you because I do feel you are doing your best > to serve the interests of the community. But it also feels like dogma > to me, much like the cookie-phobic, ultra-data security madness that > plagues me at home. > >> Perhaps if we better understand what you use the shell for, we can >> help craft CI jobs which will both a) accomplish the task and b) >> provide everyone with more visibility into what's going on, as >> opposed to some cryptic cron job. Feel free to file bugs in Community >> / Jenkins for the tasks you need assistance with. >> >> > Feel free to open problem reports that we can promptly do nothing > about. No, expect nothing and you will not be disappointed. I will > try to make due without. >> >> Denis >> >> >> On 2019-08-27 12:46 p.m., Ed Merks wrote: >>> >>> Matt, >>> >>> So in the end, a restricted shell is essentially so crippled as to >>> be effectively useless, and there exists no actual concrete >>> "definition" of what, if anything, useful might in reality be >>> accomplished with a restricted shell. >>> >>> I should point out that this is quite different from the impression >>> that was presented earlier in this process, so I'm disappointed in >>> how this has been presented and handled. It feels to me like a >>> process of decree where there is no recourse: >>> >>> "We've come to claim your property to build a new highway; we're >>> very sorry that you'll have to move out before the end of October, >>> but it is for the greater good." >>> >>> Regards, >>> Ed >>> >>> >>> On 27.08.2019 16:44, Matthew Ward wrote: >>>> Hi Ed, >>>> >>>> The restricted shell was originally created with the goal of >>>> providing committers a way to interact with the downloads/archive >>>> filesystems for releng activities, and version control systems >>>> without providing a general purpose shell. So naturally the >>>> command set available leans in that direction(mv,cp,mkdir,git etc). >>>> >>>> We are certainly willing to discuss adding extra commands either >>>> temporarily or permanently, but I want to make it clear that the >>>> goal is not to reproduce bash. >>>> >>>> -Matt. >>>> >>>> >>>> >>>> >>>> On Mon, Aug 26, 2019 at 9:58 AM Ed Merks <ed.me...@gmail.com >>>> <mailto:ed.me...@gmail.com>> wrote: >>>> >>>> What will we be able to do in restricted shell? Using vi is a >>>> very basic activity. I suppose there must be some good reason >>>> why that's restricted? Earlier I was under the impression that >>>> such simple things would continue to work, but now I have to >>>> wonder. But then it was mentioned that things we discover >>>> needed could become unrestricted... >>>> >>>> >>>> On 26.08.2019 15:35, Matthew Ward wrote: >>>>> Hi David, >>>>> >>>>> Thanks for the questions. >>>>> >>>>> Users with the restricted shell will have the same home >>>>> directories that they do currently, which will remain the >>>>> place for authorized keys. You won't be able to >>>>> edit(vi/emacs/ed) files directly within the restricted shell, >>>>> so you will need to upload them via scp/rsync. If you want a >>>>> more 'interactive' type of access I'd suggest looking into >>>>> using libfuse, and specifically the sshfs file system. >>>>> >>>>> The restricted shell allows rsync, so there should be zero >>>>> impact. If you'd like to test in advance, drop me a line and >>>>> I'll set you up. >>>>> >>>>> -Matt. >>>>> >>>>> On Sat, Aug 24, 2019 at 3:23 PM David Williams >>>>> <david_willi...@acm.org <mailto:david_willi...@acm.org>> wrote: >>>>> >>>>> On 8/23/19 14:24, Matthew Ward wrote: >>>>>> Hi Everyone, >>>>>> >>>>>> I just wanted to follow up with a reminder that on >>>>>> August 28th we will be moving committers that have an >>>>>> actual shell on Eclipse.org to our restricted shell. >>>>>> >>>>>> I'd like to thank both Donat and Etienne on the Buildship >>>>>> RelEng team who volunteered to test this change, and >>>>>> helped me confirm that this change should be minimally >>>>>> disruptive. >>>>>> >>>>>> If you have any questions, please let me know. >>>>>> >>>>>> -Matt. >>>>>> >>>>> >>>>> Thanks for the reminder. >>>>> >>>>> Will those of use that still want to use 'scp' and similar >>>>> still have a 'home directory' (on "build"?) and is that >>>>> still the place for .ssh/authorized_keys2? Or, does all >>>>> that change with "restricted shell"? >>>>> >>>>> If a change, can you point me to instructions on how to >>>>> set that up? I would assume some form of "ssh-copy-id >>>>> hostname" but thought best not to assume and ask explicitly. >>>>> >>>>> In case you are wondering, the use case, for using scp and >>>>> similar is to download a number of builds to my local >>>>> machine (without going through web interfaces). >>>>> Now that I think of it, I currently use rsync via ssh, >>>>> such as >>>>> >>>>> rsync -a -e ssh ${committer_id}@build.eclipse.org:$ >>>>> <mailto:committer_id...@build.eclipse.org:$>{dlpath} >>>>> "${output_dir}" >>>>> >>>>> Will that still work with a restricted shell? Or, will I >>>>> need to convert to "scp"? >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> _______________________________________________ >>>>> cross-project-issues-dev mailing list >>>>> cross-project-issues-dev@eclipse.org >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> To change your delivery options, retrieve your password, >>>>> or unsubscribe from this list, visit >>>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> cross-project-issues-dev mailing list >>>>> cross-project-issues-dev@eclipse.org >>>>> <mailto:cross-project-issues-dev@eclipse.org> >>>>> To change your delivery options, retrieve your password, or >>>>> unsubscribe from this list, visit >>>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >>>> _______________________________________________ >>>> cross-project-issues-dev mailing list >>>> cross-project-issues-dev@eclipse.org >>>> <mailto:cross-project-issues-dev@eclipse.org> >>>> To change your delivery options, retrieve your password, or >>>> unsubscribe from this list, visit >>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >>>> >>>> >>>> _______________________________________________ >>>> cross-project-issues-dev mailing list >>>> cross-project-issues-dev@eclipse.org >>>> To change your delivery options, retrieve your password, or unsubscribe >>>> from this list, visit >>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >>> >>> _______________________________________________ >>> cross-project-issues-dev mailing list >>> cross-project-issues-dev@eclipse.org >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe from >> this list, visit >> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
