1 |
On 07/05/2016 01:17 PM, NP-Hardass wrote: |
2 |
> On 07/05/2016 09:07 AM, james wrote: |
3 |
>> On 07/05/2016 06:25 AM, Rich Freeman wrote: |
4 |
>>> On Mon, Jul 4, 2016 at 11:26 PM, Aaron Bauman <bman@g.o> wrote: |
5 |
>>>> |
6 |
>>>> The subject of this particular mailing list post is a little alarming |
7 |
>>>> and |
8 |
>>>> over reactive. We are not running around p.masking everyone's |
9 |
>>>> packages, but |
10 |
>>>> issues that have been outstanding for years often result in such |
11 |
>>>> courses of |
12 |
>>>> action. I personally told Anthony I should have requested his |
13 |
>>>> assistance |
14 |
>>>> initially on the matter, and I do apologize for that. He is an active |
15 |
>>>> developer who would respond in a timely manner. So once again, I do |
16 |
>>>> apologize. |
17 |
>>> |
18 |
>>> Thanks, and my intent wasn't to suggest that I thought there was any |
19 |
>>> kind of a trend here. I just wanted to agree that this shouldn't be |
20 |
>>> how it happens. It sounds like we're already on the same page, which |
21 |
>>> isn't surprising since this was the first complaint I've heard in a |
22 |
>>> while. |
23 |
>>> |
24 |
>>>> Finally, that does not dissolve the developer of providing usable, |
25 |
>>>> substantiated, and verifiable information regarding the vulnerabilities. |
26 |
>>>> The idea that a developer gets to choose whether or not they do so |
27 |
>>>> should |
28 |
>>>> not be considered. |
29 |
>>> |
30 |
>>> Also agree. I think we need to have a reasonable security policy, but |
31 |
>>> clearly there can't be unresolved questions about whether a particular |
32 |
>>> package-version is vulnerable or not. If we don't get a question like |
33 |
>>> that resolved in a timely manner then the version should be masked. |
34 |
>>> Users can then make an informed decision as to whether they want to |
35 |
>>> take the risk in unmasking it. |
36 |
>>> |
37 |
>>> Our security policies are a tree-wide QA commitment that our users |
38 |
>>> rely on. We shouldn't advertise a security policy that we aren't |
39 |
>>> willing to enforce. |
40 |
>> |
41 |
>> As an old C hack, and user of gentoo for over a decade, I understand the |
42 |
>> positions being articulated herein. However, I think there is a |
43 |
>> fundamental perspective that is missing, so I shall attempt to |
44 |
>> illuminate that perspective. 'C' is still a magical and most important |
45 |
>> language. It is the transitive language between large, complicated |
46 |
>> systems, and hardware. Like it or not, without hardware, there are no |
47 |
>> systems. |
48 |
>> |
49 |
>> There are many new and modern languages with wonderful features. I get |
50 |
>> that, and appreciated that they are needed and desired. But modern |
51 |
>> (security and usefulness) metrics are being applied to old codes that |
52 |
>> are useful for a variety of reasons, beyond compiling them and using them. |
53 |
>> |
54 |
>> There is an intersection between minimal unix (minimal gentoo in our |
55 |
>> case) and embedded systems. Docker, many would cite as the leader in |
56 |
>> commercial container deployments, has realized that minimal is better, |
57 |
>> faster, easier to secure and can always be 'scaled up' by adding more |
58 |
>> codes (hence they subsumed Alpine Linux). |
59 |
>> |
60 |
>> Gentoo has a rich, legacy in old, simpler codes that bridge embedded |
61 |
>> linux to (bloated/full-featured) linux. Those old codes that appear to |
62 |
>> many as useless, indeed form a narrow bridge to both the past and the |
63 |
>> logic/tricks/methods to get various types of hardware working in a |
64 |
>> minimal or embedded environment. They are often 'single function' codes |
65 |
>> without the complexity of a gui or bloated formations. They are easy to |
66 |
>> read and with a CLI focus, allow a developer to see how some things |
67 |
>> work. Those old codes, folks are quick to purge now, often contain |
68 |
>> logical information on how to talk to hardware. (think ethernet for one). |
69 |
>> |
70 |
>> |
71 |
>> So when we had 'the attic' I was fine with codes being purged by |
72 |
>> whomever. There is no easy to use equivalent in github (and believe me, |
73 |
>> I'm a noooooob at github), so I have much anxiety about what, from my |
74 |
>> perspective, appears to be needless purging of many old codes. I have no |
75 |
>> problem with removal from the official tree, but I'd like to keep them |
76 |
>> around, regardless of any security, brokeness or un-maintained status. I |
77 |
>> completely OK with tree-cleaning, just a soon as the ink dries on the |
78 |
>> new wiki pages that guarantee archival of old codes. Security, is |
79 |
>> important, but not the main issue from my perspective. Maintenance of |
80 |
>> old codes, particularly written in C and related to hardware or logic of |
81 |
>> minimal systems, is keenly important to me. If gentoo remains 'a good |
82 |
>> stuart' of these codes, it just another mechanism |
83 |
>> to distinguish our distro, imho. |
84 |
>> |
85 |
>> So I would ask (beg if necessary) the kind folks that are the gentoo |
86 |
>> devs to figure out a way to archive those old codes, and document how to |
87 |
>> retrieve them, via github, as the attic too is probably like sunrise and |
88 |
>> such, headed towards deprecation and the chopping block..... |
89 |
>> |
90 |
>> |
91 |
>> Thanks, |
92 |
>> James |
93 |
>> |
94 |
>> |
95 |
> |
96 |
> Here's a solution that handles that doesn't require fancy git knowledge |
97 |
> and uses Gentoo infrastructure: |
98 |
> |
99 |
> 1) Navigate to https://gitweb.gentoo.org/repo/gentoo.git (or any other |
100 |
> gentoo repo) |
101 |
> 2) Click "Tree" |
102 |
> 3) Navigate to the level ABOVE the one you are interested in, for |
103 |
> example, if you want app-misc/foobar, navigate into app-misc. |
104 |
> 4) To the right of your desired entry, click "Log" |
105 |
> 5) This will display the history of the package, allowing you to browse |
106 |
> it at any time, (you in particular want the one before the ebuild was |
107 |
> removed) (Click your desired commit) |
108 |
> 6) Click the name of the category/package on the "Tree" line to view the |
109 |
> tree at that point in time. ie, |
110 |
> tree 02d93ae662fb1a813380775612e35e819d67e303 |
111 |
> /app-accessibility/SphinxTrain (you would click |
112 |
> "app-accessibility/SphinxTrain" |
113 |
> 7) View and download your desired files by clicking on "Plain" on the right |
114 |
> |
115 |
> Protips: |
116 |
> *You can view the log of any package (removed or not) with: |
117 |
> https://gitweb.gentoo.org/repo/gentoo.git/log/<category>/<pkgname> |
118 |
> |
119 |
> *You can view files as of last commit before removal of any package with: |
120 |
> https://gitweb.gentoo.org/repo/gentoo.git/tree/<category>/<pkgname>?id=<lastcommitbeforeremoval> |
121 |
> |
122 |
> * If you don't know the last commit before removal, juts load up the |
123 |
> removal commit and copy the commit hash of the "Parent" link to get the |
124 |
> commit before that |
125 |
> |
126 |
> Tada! Attic restored ^_~ |
127 |
|
128 |
Not bad, at first glance. Not too bad at all! Let me work with this a bit. |
129 |
|
130 |
THANKS! |
131 |
|
132 |
James |