Denis,
Comments below.
On 27.08.2019 20:47, Denis Roy wrote:
Ed,
Would you feel better setting aside your winter instead of summer?
Well, I'd prefer the fall if given a choice.
We operate an open/transparent organization. Your shell-based
mission-critical tasks are trapped inside your shell.
Yes, that's why I've been migrating them. I agree they're better as
jobs, but some of us are old, and we're used to doing things other
ways. We're just not the new cool kids. In the old days, shell access
wasn't insane.
Putting them in a CI would do everyone a world of good, so that others
can contribute to your enjoyment of summer.
Of course I practically live for the good of others. :-P
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.
You're not throwing dogma in my face are you!?
And you're right - Jenkins vs. shell is not much better. The new Jiro
(on Kubernetes) is.
It's hard to keep up with the de jour trends. They change almost as
quickly as one changes one's underwear. Will what I do on Jenkins,
which worked fine in a shell, but is insane there, stop working on Jiro
when its been Kubernetized into the latest jargon-laden trend
technology? Or is there a migration path involved?
Matt has been doing some digging and I believe has some potential
workarounds for yourself, and Markus. Stay tuned.
I'd probably be done with my migration if the infrastructure would just
cooperate. But then what would I complain about?
This just annoys the living heck out of me though:
[INFO] Unpacking org.bouncycastle.bcprov_1.61.0.v20190602-1335...
[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]
Why did that start at 3:00PM today, just as I try to get the p2 indexer
working? It's not that it couldn't resolve the thing, it can't download
it, even though it's resolved. Why?! Why now when I need builds to
work, when I need to get M3 working in the tiny gap between
Mac-can't-sign and Tycho-can't-download-file.
Thanks for understanding,
As I said, sorry for ragging on you. I know it's hard to balance all
these things. But I'm just annoyed and very frustrated. I'm sure many
will not appreciate how much gets done in the background until it's no
longer done at all.
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
_______________________________________________
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
