Hi Ed,
Another committer uses sshfs, and I suggest you look into it.
Essentially it allows you to 'mount' the remote file system over sftp/scp
into your local file system:
sshfs -o follow_symlinks eme...@build.eclipse.org:/ /some/local/dir
This would allow you to browse and edit files using whatever tools you have
installed locally. Now there will be some delay as files are fetched or
placed but I think it would provide you with essentially the same
experience you have now.
-Matt.
On Tue, Aug 27, 2019 at 2:26 PM Ed Merks <ed.me...@gmail.com> 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> 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>
>> 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:${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
>>> 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 listcross-project-issues-...@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe from
>> this list,
>> visithttps://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 listcross-project-issues-...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from
> this list,
> visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> _______________________________________________
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from
> this list,
> visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> _______________________________________________
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from
> this list,
> visithttps://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
