1 |
Hi there! |
2 |
|
3 |
During the last web-apps meeting we decided that we would like to |
4 |
further discuss the upstream requirements a package needs to fulfill |
5 |
in order to be added to the portage tree by the web-apps team. |
6 |
|
7 |
The current proposition is specified here: |
8 |
|
9 |
http://svn.gnqs.org/projects/gentoo-webapps-overlay/wiki/UpstreamRequirements |
10 |
|
11 |
In my discussion with Stuart this morning I did realize that there are |
12 |
not too many packages available that would actually meet these |
13 |
criteria. So far we probably have around five in the portage tree. |
14 |
|
15 |
The main blocker are the security requirements since many projects do |
16 |
not provide special security contacts or mailing lists devoted |
17 |
security. For some projects this probably implies that they actually |
18 |
don't care too much about security. |
19 |
|
20 |
It is clear that it is not appealing for the web-apps herd to care for |
21 |
a high number of unsafe packages in the tree especially since |
22 |
web-applications by their very nature should be much more secure than |
23 |
many applications only used locally. A high number of security bugs or |
24 |
a slow response to these will not shine the best light on our distro. |
25 |
|
26 |
So reliable security information from upstream would help the web-apps |
27 |
team to react in a prompt and timely fashion when a security issues |
28 |
arises. |
29 |
|
30 |
On the other hand we would probably be forced to reduce the tree to a |
31 |
small number of web-apps if we enforce the requirements very |
32 |
stringently which might not be very appealing to our users. |
33 |
|
34 |
I also had the impression that one of the packages that has been a |
35 |
mojor problem last year (phpBB) actually nearly fulfills the current |
36 |
requirement proposals (at least to a greater extend than many of the |
37 |
smaller packages) but nonetheless has caused quite an amount of grief. |
38 |
Having bugs tracker, announcement lists and security mails might not |
39 |
always cover up for direct experience with the project itself. |
40 |
|
41 |
So I would suggest that we enforce the current proposal in the all |
42 |
cases where we do not have a developer in our herd actively using the |
43 |
package. I think that any dev's of our herd that actively uses a |
44 |
package is probably a better source of information about the security |
45 |
of the package than the mailing lists of the project. At least as long |
46 |
as I assume that we care a lot more about the security of our servers |
47 |
than the average user. But I believe that's a safe bet. |
48 |
|
49 |
If there is no dev with an active interest in the package all we have |
50 |
are the information from upstream. In this case I do believe the |
51 |
requirements make absolute sense. |
52 |
|
53 |
My .2 cents :) |
54 |
|
55 |
Cheers |
56 |
|
57 |
Gunnar |
58 |
|
59 |
|
60 |
-- |
61 |
Gunnar Wrobel Gentoo Developer |
62 |
__________________C_o_n_t_a_c_t__________________ |
63 |
|
64 |
Mail: wrobel@g.o |
65 |
WWW: http://www.gunnarwrobel.de |
66 |
IRC: #gentoo-web at freenode.org |
67 |
_________________________________________________ |