I know this sounds ridiculous, from a security researcher who has had
every version of dropstat and dropttdb.c for the entirety of archs and
os's running them:
CDE is back and re-released with a (better but likely still broken
codebase).
Grab the source maybe if you can afford to just firewall all RPC and X,
etc...
I always liked the exploit lurid found in sadmind, not one of the silly
overflows, but the AUTH_UNIX bug. I counted several overflow exploits
during the time that was private.
n...@mod.net
On 2017-05-12 01:10 AM, Till Wegmüller wrote:
If we talk bigger components like XFCE i would say that this is pretty
much how we are handeling them right now. We only take in these when
we know that a Contributor is able to support them over a period of
time. Otherwise we leave try to put stuff like this into SFE or pkgsrc
where there are people (and buildservers) providing packages for many
things.
I would say that this seems the way to go with the bigger Components.
---
Greetings
Till
On 12.05.2017 09:27, Dariusz Sendkowski wrote:
In my opinion, the current system looks fine.
Having a maintainer per component could be a nightmare for both
maintainers and contributors. Maintainers are usually bottlenecks for
various reasons no matter how hard they try not to be.
It could slow down the whole process significantly. Right now, it
seems to run pretty flawlessly.
But how does it work for big and complex components (like desktop
environments)? Should they be rejected due to the lack of the
contributor's maintenance guarantee?
When I look at the contributors' list I see that people appear and
disappear and that's a natural process.
This implies that nobody can guarantee that they will maintain
components they add (I mean the bigger ones).
2017-05-12 6:22 GMT+02:00 Alexander Pyhalov <a...@rsu.ru
<mailto:a...@rsu.ru>>:
On 11.05.2017 22:13, Peter Tribble wrote:
On Thu, May 11, 2017 at 6:56 PM, Aurélien Larcher <
aurelien.larc...@gmail.com
<mailto:aurelien.larc...@gmail.com>>
wrote:
The question raised is whether we should formalize a
maintaining process
for some important components or groups of components.
At some point I joked about a campaign going like "Adopt a
package".
There are downsides to having a formal owner: they can become
a
bottleneck, and it might discourage others to contribute in an
area
where there's an individual (or individuals) listed. Also,
people may be
reluctant to contribute if there's a prospect of being
lumbered with
the responsibility going forward.
But, if you can avoid that, then there are benefits to having
what we
would call "Subject Matter Experts" for components or groups.
Having
someone who is reasonably familiar with the component,
preferably
someone who uses it, is useful as a source of help and advice,
and
having a list of such people and their specialities would be
useful to
other contributors.
Putting such a list on display would also show that OI wasn't
just a
one or two person effort, which would be good.
Yes, this idea seems reasonable. BTW, recently github started
suggesting reviewers
and it does it rather well.
---
System Administrator of Southern Federal University Computer
Center
_______________________________________________
oi-dev mailing list
oi-dev@openindiana.org <mailto:oi-dev@openindiana.org>
https://openindiana.org/mailman/listinfo/oi-dev
<https://openindiana.org/mailman/listinfo/oi-dev>
_______________________________________________
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
_______________________________________________
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
_______________________________________________
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
