jgay has quit [Quit: No Ping reply in 180 seconds.]
phildini has quit [Ping timeout: 255 seconds]
compuguy has quit [Quit: Ping timeout (120 seconds)]
JonTheNiceGuy has quit [Ping timeout: 255 seconds]
simpson has quit [Ping timeout: 255 seconds]
phildini_ is now known as phildini
cbaines has joined #sandstorm
simpson has joined #sandstorm
Mitar has quit [Ping timeout: 240 seconds]
harish has joined #sandstorm
JonTheNiceGuy has joined #sandstorm
Mitar has joined #sandstorm
compuguy has joined #sandstorm
ogres has quit [Quit: Connection closed for inactivity]
compuguy has quit [Ping timeout: 255 seconds]
compuguy has joined #sandstorm
pie_ has quit [Ping timeout: 248 seconds]
<bignose>
sigh. So it's another instance of “you shouldn't want to do that with Sandstorm”?
<bignose>
we have capable apps, that get crippled because we can't get SSH access or filesystem access to interact with them.
<bignose>
a Git repository that I can't interact with via SSH is a needlessly crippled Git repository.
<bignose>
this is a symptom of a larger problem in Sandstorm, IMO. The claim is to make these apps available to many people; but there seems to be no consideration for granting the user actual access to the app, except via HTTP.
<simpson>
bignose: FWIW don't think of it as "crippling"; we call this "taming", and it is a big part of the capability-security strategy for interoperating with existing non-capability-safe systems.
<simpson>
(I'm not with Sandstorm but I do applied capability-safe research.)
<crab>
that's cold comfort when it doesn't work. :-)
<simpson>
I honestly feel that Sandstorm is quite warm and comforting in terms of supporting legacy applications. My current position is that all of this sort of code should be written in Monte, my object-capability language.
<simpson>
I'm just trying to help explain the philosophy of Sandstorm's design.
<bignose>
SSH is secure, reliable, mature, and general purpose. Why do you call it “legacy”?
<simpson>
git would be the legacy application in this case. There's nothing wrong with the SSH protocol, aside from what's well-documented and not innate to SSH.
<crab>
if i understand correctly, most of the point of sandstorm is to support legacy applications. if applications were written in a secure, capability-sensible way, you wouldn't need sandstorm, just an identity provider.
jemc has quit [Ping timeout: 248 seconds]
<simpson>
Yep.
<bignose>
In what sense is Git a “legacy” application? If you just mean by that word “prior to Sandstorm”, that doesn't seem conducive to effective communication.
<bignose>
By saying “legacy application” you are, whether or not you intend it, communicating that you think it stays around only until we replace it, which we're actively trying to do.
<bignose>
if you don't mean that, I think “legacy” isn't the word you want to use.
<simpson>
I mean "legacy" in the sense of "not being capability-safe and nonetheless sending bytes over The Network", which Monte is aimed at deprecating.
<bignose>
that seems rather orthogonal to the discussion about Sandstorm. I don't think “re-implement it in Monte” is of much relevance to addressing the use cases of Sandstorm.
<bignose>
and “not implemented in something like Monte” is also a very opaque meaning to have for “legacy”.
<simpson>
I was pretty clear on this being my personal position, and only elaborated when asked.
<bignose>
simpson: so, forgive me, but I think I can't understand what you mean when you responded earlier to me, because I can't know what strange meanings oyu have for the words you use.
<simpson>
bignose: My view is that nearly all software folks use is broken and that we should be working to deprecate massive amounts of it.
<bignose>
simpson: so, by that position, you think most of the software on Sandstorm and most of the software users want on Sandstorm, should be deprecated.
<bignose>
I hope you'll understand that isn't a helpful attitude when discussing what people actually want to do with Sandstorm.
<simpson>
bignose: Yes please.
<simpson>
I'm just trying to help fill in why Sandstorm might seem to endemically have "a larger problem".
<simpson>
Anyway, you're right that I'm not able to help you. Sorry. I'll go find something else to do.
samba_ has joined #sandstorm
samba_ has quit [Ping timeout: 240 seconds]
<ocdtrekkie>
My hope is that we'll see more capability-based software in the future. I definitely feel like there is a major difference between existing (or "legacy") software and what today, I think should be a baseline expectation of security.
<ocdtrekkie>
bignose: As far as SSH access, it's conceivably possible, but would require a fair bit of development for Sandstorm. Because you either need to allow an app completely arbitrary IP networking access (which is currently possible, and used by isd's IRC Idler), which requires you be an admin on the Sandstorm server, or some sort of API needs to be make to allow SSH to be used.
<ocdtrekkie>
Sandstorm's roadmap/documentation contains the idea of "drivers", which would be features that admins could permit, more or less, to allow apps to use other protocols than HTTP.
<ocdtrekkie>
I suspect Sandstorm would need a lot more developers getting involved in the core platform development for those to become a reality any time soon.
<crab>
yeah.
<JonTheNiceGuy>
Crab, in the meantime, sandstorm natively talks http based protocols. Git supports http as a transport, so that's why they use it like that.
<JonTheNiceGuy>
It doesn't currently talk SSH as a native protocol
<crab>
crab → bignose
<JonTheNiceGuy>
D'oh, my bad.
<bignose>
whereas for secure communication with a Git repository, HTTP is deprecated and SSH is preferred.
<kentonv>
yeah, bignose, the problem here is entirely a shortage of engineering. In order to support SSH, we need to teach Sandstorm to understand what SSH is doing and how to make it capability-secure. That's just not trivial.
<bignose>
so, I consider GitWeb crippled if it's deployed without SSH enabled.
<kentonv>
I would like for there to be SSH access
<kentonv>
but there are a lot of things I want in Sandstorm
<bignose>
I understand that it's a matter of people putting in the work to make that happen
<bignose>
but until then, GitWeb isn't deployed securely IMO.
<kentonv>
out of curiosity, why do you consider HTTPS insecure?
<bignose>
less secure than SSH. Because HTTPS is based only on host keys.
<bignose>
not on a key for the individual.
<kentonv>
each individual has a credential that authenticates them, though
<kentonv>
and with sandstorm it's a different, high-entropy credential for each repository (not a user-chosen password)
<kentonv>
arguably SSH is vulnerable to MITM, since there's no good secure key verification mechanism
<kentonv>
everyone just trusts on first use
<kentonv>
HTTPS has -- sort of -- solved that, with the CA system. Though of course, it has many problems.
<kentonv>
everything is a trade off
<kentonv>
I think it's not correct to say that SSH is "more secure" than HTTPS. It's different set of trade-offs.
<bignose>
it's not my position that HTTPS is insecure.
<bignose>
yes.
<bignose>
and the security that is easier to manage is with an SSH key for each person, that I can upload to the Git repository manager.
<kentonv>
I would agree that it's easier to manage mainly because git's tooling for SSH keys is more mature -- not because the protocol is fundamentally better
<bignose>
and can remove when I no longer want that person to have access to the repository.
<kentonv>
sandstorm provides you a way to revoke users
ocdtr_mob has joined #sandstorm
<kentonv>
if you remove someone's access through the "who can access" dialog, their git client will no longer be able to connect
<crab>
yep, that (revocation) works just fine.
<kentonv>
and this is the thing -- we wand Sandstorm to do this kind of access control; we don't want each app to have to implement it
<kentonv>
which is why Sandstorm needs to understand the protocols being used
<kentonv>
I would love to extend Sandstorm to understand SSH so that you can manage your SSH keys at the Sandstorm level, then connect to various grains with it
<bignose>
“each app” doesn't have to. That's why Git uses SSH keys, because it's a widely implemented standard.
<kentonv>
but, it's work, and I'm not sure when that work will happen
<bignose>
so no, I don't buy the “Sandstorm wants to control the access” as a reason not to offer SSH access.
<kentonv>
traditionally, the app has to implement SSH support, including key management
<kentonv>
github has a settings page where you upload you keys
<kentonv>
gitlab too, in non-Sandstorm mode
<kentonv>
if we let the apps do that with Sandstorm, and let them receive SSH connections directly, then when you told Sandstorm to revoke someone's access, it wouldn't know how to revoke their SSH access
<crab>
"you can do whatever you want, but if you don't do anything insecure then it is probably secure" is not a very compelling proposition.
<bignose>
I don't want Sandstorm to revoke their SSH access. I want the app *which already knows how to do that*, to do it.
<kentonv>
then you don't want Sandstorm
<kentonv>
a core objective of Sandstorm is to move access control into the system
<bignose>
that is, I want to do what GitWeb expects me to be able to do, as the GitWeb administrator.
<kentonv>
so that apps can't screw it up
<kentonv>
and so that Sandstorm can provide a unified, consistent view of access control
<kentonv>
and can implement global policies across all apps
<ocdtr_mob>
The primary issue there bignose, is now you have to worry about GitWeb vulnerabilities.
<kentonv>
now, it's perfectly fine to say you don't want any of that
<kentonv>
and you really do want each app to do its own thing independent of the rest
<kentonv>
but that's not what Sandstorm is trying to accomplish
<bignose>
it is quite frustrating that it takes many months to discover this. Seeing these apps offered in Sandstorm, only to flail trying to configure them, and then to be told Sandstorm is deliberately hobbling the ability to configure them
<bignose>
well, that leads to quite a negative impression of the Sandstorm mission.
<crab>
i can understand the frustration, but FWIW, it was clear to me that this was going to be the case before i tried out sandstorm.
<kentonv>
it's not "deliberately trying to hobble them", it's trying to do things in a way that would have a lot of advantages -- if we had the engineering manpower to polish all the edges, which unfortunately we don't
<crab>
some other things weren't clear to me (e.g., whether encryption was implemented yet, or the state of powerbox requests)
<kentonv>
I readily admit that the system in its current state is janky at best
<kentonv>
and I'm sorry that you felt duped
ocdtr_mob has quit [Ping timeout: 248 seconds]
ocdtr_mob_ has joined #sandstorm
<bignose>
the ability to configure the app is hobbled – i.e. the app has hooks to configure it, that are intentionally blocked on the Sandstorm version of the app 7-N is what I mean by “deliberately hobbling the ability to configure”.
<bignose>
that may be a provocative way to put it, but I hope that it can lead to either removing apps that have these surprising limitations
<bignose>
or to making it clearer what the limitations are, when trying to get the app working.
<kentonv>
again, Sandstorm is trying to take ownership of a lot of functionality that used to be the app's responsibility. Taking that ownership could have huge benefits, if we were able to develop it out. I don't think it's fair to say that it's "blocking" functionality.
<crab>
i agree that the limitations for each app could be spelled out more clearly.
<bignose>
so, I'll take the advice to not use Sandstorm. I wish you the best in making it work for some segment of the population.
bignose has left #sandstorm [#sandstorm]
<kentonv>
I do sympathize with the complaint that many apps which exist both on and off of Sandstorm have lost functionality on Sandstorm, due to the system being incomplete
<crab>
but replacing authentication/permission functionality in apps with the sandstorm code instead is how it's *supposed to be*
<kentonv>
I guess he left
<crab>
yeah. well, that conversation wasn't really going anywhere. :-/
<crab>
meanwhile, i'm trying to rebase dwrensha's wp changes on top of the upstream 4.8-branch, which unfortunately means reading php code.
<kentonv>
thanks for working on that
<ocdtr_mob_>
It's probably more accurate to say some app functionality is 'not yet implemented' in Sandstorm rather than 'blocked' though that suggests a likelihood of it being implemented in some timeframe.
<kentonv>
fwiw I saw dwrensha tonight. He still exists and I'm sure he'll be happy to transfer ownership if desired.
<ocdtr_mob_>
He exists!
<ocdtr_mob_>
WordPress would probably be really nice updated. They've done a lot with their editor.
<kentonv>
yeah basically bignose's problem is that Sandstorm is incomplete -- but he doesn't understand what it would look like if it were complete
<ocdtr_mob_>
That is not an uncommon problem.
<kentonv>
it's true
<kentonv>
and also, doesn't understand that if we were to "just let the apps do their thing", it would actually set back the vision
<ocdtr_mob_>
Btw, is Sandcats healthy right now? Someone has been asking and that's usually not a user problem when it happens.
<digitalcircuit>
This is likely be a bad analogy given Powerbox/etc, but it reminds me of the "Sign in with Google" and {insert service here} buttons. Google/etc manage authentication/basic profile data, leaving the website able to be revoked/no password/etc.
<kentonv>
I saw that, but I'm not aware of an issue. Globalsign's API does randomly barf sometimes.
<kentonv>
if a second person has trouble with sandcats or if the same person has trouble again at a different time then it may be worth looking into
<kentonv>
I look forward to switching over to Let's Encrypt when they start supporting wildcards...
<ocdtr_mob_>
Yup
<kentonv>
I should go to sleep
<ocdtr_mob_>
Should as well.
<ocdtr_mob_>
But I saw people chatting in IRC.
<kentonv>
heh
<ocdtr_mob_>
G'night.
<kentonv>
'night
ocdtr_mob_ has quit [Read error: Connection reset by peer]
<JonTheNiceGuy>
Night all. Thanks for weighing in. I'm a bit surprised by his assertion that HTTPS access to GIT is flawed, but shrug can't please everyone I guess.
<crab>
i'm not sure if the "hello dolly" plugin is deleted from sandstorm-app wordpress branch for some particular reason, or just because it's annoying
<JonTheNiceGuy>
Bit of both? :)
<crab>
well, there's other mystifying things in there.
<crab>
for example, one patch adds 'sandstorm/sandstorm.php' to the 'active_plugins' list, but (a) the file didn't exist, and (b) was later removed with the comment 'working on making sandstorm.php must-use'
<crab>
so without knowing more about both wordpress and sandstorm, i'm mostly just guessing at what might have made sense.
<crab>
but hey, i'm good at guessing.
demonimin has quit [Remote host closed the connection]
demonimin has joined #sandstorm
larjona__ has joined #sandstorm
harish has quit [Ping timeout: 260 seconds]
harish has joined #sandstorm
afuentes has joined #sandstorm
Telesight has joined #sandstorm
taktoa has joined #sandstorm
pie_ has joined #sandstorm
larjona__ has quit [Quit: Konversation terminated!]
samba_ has joined #sandstorm
pie_ has quit [Remote host closed the connection]
pie_ has joined #sandstorm
jemc has joined #sandstorm
pie_ has quit [Ping timeout: 255 seconds]
pie_ has joined #sandstorm
larjona_ has joined #sandstorm
larjona_ has quit [Read error: Connection reset by peer]
KCinJP has quit [Read error: Connection reset by peer]
KCinJP has joined #sandstorm
larjona_ has joined #sandstorm
larjona_ has quit [Client Quit]
bodisiw has joined #sandstorm
samba_ has quit [Ping timeout: 248 seconds]
efishta82 has quit [Ping timeout: 248 seconds]
efishta82 has joined #sandstorm
samba_ has joined #sandstorm
taktoa has quit [Remote host closed the connection]
alex_ has quit [Ping timeout: 240 seconds]
taktoa has joined #sandstorm
Anthropy has joined #sandstorm
pie_ has quit [Ping timeout: 240 seconds]
Anthropy has quit [Ping timeout: 246 seconds]
alex_ has joined #sandstorm
taktoa has quit [Remote host closed the connection]
bodisiw has quit [Quit: This computer has gone to sleep]
pie_ has joined #sandstorm
afuentes has quit [Ping timeout: 248 seconds]
taktoa has joined #sandstorm
samba_ has quit [Ping timeout: 255 seconds]
samba_ has joined #sandstorm
DanC has joined #sandstorm
<DanC>
is connecting a github webhook to a sandstorm API endpoint feasible? ISTR sandstorm requiring a special header and I doubt github supplies that.