-
-
Notifications
You must be signed in to change notification settings - Fork 709
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
Lots of apps out of date (not updated since 2016) #3129
Comments
There are a few people who are working on this. @xet7 and @JamborJan have done some work updating previously abandoned packages, and @zenhack has done some work on a newer way to package Sandstorm apps using more standard container formats (Docker). Though to be honest/blatant, Sandstorm is not getting a lot of developer attention right now overall. Note that Sandstorm's primary goal was to be able to assume that apps were malicious or broken, and therefore, most app vulnerabilities don't pose a significant risk to a Sandstorm user. The worst case scenario is really that someone who has access to a Sandstorm document with a lower permission level (say, read-only), can modify data in that document or see information they weren't supposed to. App vulnerabilities can't affect other grains/documents at all, and a grain can only be accessed in any way by a user who has been given access to the grain via Sandstorm. (As such, a document you don't share with anyone is more or less invulnerable to everything, in theory.) I am involved in app approval for the market, and we are not held up on that side, we need people to maintain and update packages, and in some cases, the original packagers were Sandstorm.io employees and in others, the people who ported the app to Sandstorm are just not interested in updating them at present. If people can get the packages updated and working, we can get them in the market. |
I would add that the same security page you linked itemizes ways Sandstorm mitigates or completely negates many categories of security risk. My understanding is that integrating the applications with Sandstorm's security/packaging model is a significant amount of work, so automating the process isn't practical. I would love to be wrong about that. |
Quoting Tyler Rick (2019-03-19 14:46:52)
this platform is stagnant and no longer maintained (which maybe it
isn't?).
Active development has definitely stalled since sandstorm-the-business
disappeared, though the platform still sees basic maintenance. There
have been a couple things that have gone in since the company
disappeared (most notably i18n), but there hasn't been much in the way
of new features.
It's also hard to take claims of [1]security very seriously
* Do we need to find maintainers (or team of maintainers) for some of
these?
I think this is the biggest thing; most of the out of date apps are
simply unmaintained. There are a couple folks maintaining some things
under the [sandstormports](https://github.com/sandstormports) org. They
could use more hands.
Build automation would also definitely make maintenance easier. See also
discussion at:
zenhack/docker-spk#9
|
I was really, really interested in this platform as I read about it... And then I saw that most of the apps I'm interested in using from the marketplace are woefully out of date. That's kind of a deal-breaker. Is anyone working on improving this?
If you want people to use this platform, you need to provide frequent updates and the current releases of the apps people want to use!
Really old releases are going to scare people away and make them think this platform is stagnant and no longer maintained (which maybe it isn't?). It's also hard to take claims of security very seriously when the apps available in the marketplace don't even have the latest security releases that the developers have provided.
Here are some examples:
What problems have led to this situation, and how can we fix them?
Do we need to automate the builds so they happen automatically whenever the developer releases a new release upstream? I suspect this would help tremendously, so that it's not a manual chore that is easy to forget about or procrastinate, especially if it's up to a single person to do the release...
Do we need to find maintainers (or team of maintainers) for some of these?
What else would help?
The text was updated successfully, but these errors were encountered: