Re: Code Signing Certificate for Windows (was Re: Mac system Catalina)
Yes, we do, and our yearly order even includes some certs for AOO :-) I'll provide the contact of our volunteer cert manager, privately to the PMC. Cheers, Greg Stein Infrastructure Administrator, ASF On Tue, Oct 29, 2019 at 11:54 AM Peter Kovacs wrote: > Hi Greg, > > Do we have a service for windows certifications? I remember some service > with Symantec. I'd that works with MSN can you give pointers? > > Thx for the support! > > All the best > Peter > > Am 29. Oktober 2019 11:13:53 MEZ schrieb Pedro Lino < > pedro.l...@mailbox.org>: >> >> Hi all >> >> On October 28, 2019 at 10:32 PM Dave Fisher wrote: >>> >>> There is an offer from Microsoft for Apache committers to get a free MSDN >>> license. If that gives access to the proper signing keys then that would be >>> the way to go. >>> >> >> Is it possible for one of the PMC members to find out if there are >> exceptions for non-profit organizations such as Apache? >> >> Warning: I'm not a developer so maybe some interpretations could be wrong >> >> As far as I can investigate in MSDN blogs, all developers buy their >> certificates from various providers (Comodo, Symantec, Thawte, etc) and >> Microsoft only certifies it's own binaries (which to me is a bit suspicious >> but they do own the game :) ) >> >> https://blogs.msdn.microsoft.com/ieinternals/2011/03/22/everything-you-need-to-know-about-authenticode-code-signing/ >> https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate >> https://aboutssl.org/cheap-code-signing-certificate-providers/ >> >> Developers can create their local certificates but only for testing >> >> https://docs.microsoft.com/en-us/windows/win32/appxpkg/how-to-create-a-package-signing-certificate >> >> Hope this helps, >> Pedro >> >> On Oct 28, 2019, at 3:22 PM, Peter Kovacs wrote: >>>> >>>> I do not want to spend money on this service, without having tried with >>>> infra or Microsoft directly. >>>> I am sure the ASF has something. And if not I am sure Microsoft gives us >>>> access at better conditions then the 3rd party offer. >>>> >>>> Am 28. Oktober 2019 20:59:15 MEZ schrieb Pedro Lino >>>> : >>>> >>>>> Hi Peter >>>>> >>>>> >>>>> For Windows it would help in a first step if someone can search >>>>>> >>>>> the resources on MSN and post links of the validation process described >>>>> by MS. >>>>> >>>>>> >>>>>> >>>>> This is what is needed for Windows Certification: a Code Signing >>>>> Certificate >>>>> https://www.ksoftware.net/code-signing-certificates >>>>> >>>>> Giving that this is a distributed project, I would say that the OV Code >>>>> Signing is the most appropriate (otherwise only one person will have >>>>> the encrypted hardware token) >>>>> >>>>> Hope this helps. >>>>> >>>>> Does Apache OpenOffice have any funds? >>>>> >>>>> Regards, >>>>> Pedro >>>>> >>>>> >>>>> Am 28. Oktober 2019 17:45:35 MEZ schrieb Matthias Seidel < >>>>>> >>>>> matthias.sei...@hamburg.de mailto:matthias.sei...@hamburg.de >: >>>>> >>>>>> Hi Pedro, >>>>>>> >>>>>>> Am 28.10.19 um 17:40 schrieb Pedro Lino: >>>>>>>> >>>>>>>>> >>>>>>>>>>>> Do you volunteer? Remember, we all are only volunteers... >>>>>>>>>>>> >>>>>>>>>>> ;-) >>>>>>>> >>>>>>>>> I believe these two issues should be enough >>>>>>>>>>>> >>>>>>>>>>> reason for a 4.1.8 release. >>>>>>>> >>>>>>>>> Welcome to the team! >>>>>>>>>>>> >>>>>>>>>>> I don't understand the cynicism. >>>>>>>>> I believe I have contributed quite a bit with translation, bug >>>>>>>>> >>>>>>>> reporting and build testing. Apparently that is not enough for >>>>>>>> >>>>>>> this >>>>>> >>>>>>> project? >>>>>>>> >>>>>>>>> >>>>>>>>> Too bad! >>>>>>>>> >>>>>>>> >>>>>>>> Well, someone has to deliver... >>>>>>>> >>>>>>>> No cynicism, it was just an invitation. >>>>>>>> >>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Pedro >>>>>>>>> >>>>>>>>> >>>>>> -- >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> >>> -- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >>
Re: ooo-forums downtime
status.apache.org reports services that are *down*, rather than individual
bugs/problems.
Thanks,
-g
On Wed, Jan 10, 2018 at 2:03 AM, FR web forum wrote:
> I note that give you this information next time
> Why these outages are not reported in http://status.apache.org
>
>
> - Mail original -
> > De: "Chris Lambertus"
> > À: priv...@infra.apache.org
> > Cc: "Andrea Pescetti" , dev@openoffice.apache.org
> > Envoyé: Mercredi 10 Janvier 2018 03:22:04
> > Objet: Re: ooo-forums downtime
> >
> >
> > I’ve pushed a change which fixes this on the database side. I also
> > saw the email about the forum being down yesterday, but it was a
> > transient problem. It would be helpful for me to know what the start
> > time and duration was for any future reports of slowness or outages.
> >
> > -Chris
> >
> >
> >
> >
> >
> >
> >
> > > On Jan 4, 2018, at 5:49 PM, Chris Lambertus wrote:
> > >
> > >
> > > There may not be anything we can do about this until phpBB is
> > > upgraded.
> > >
> > > I put the wiki database move on hold until I can look into it more.
> > >
> > >
> > >> On Jan 4, 2018, at 2:42 PM, Andrea Pescetti
> > >> wrote:
> > >>
> > >> CCing Chris for the two messages below. Maybe a SQL version issue?
> > >> Regards,
> > >> Andrea.
> > >>
> > >> On 04/01/2018 21:59, Hagar Delest wrote:
> > >>> Note: same for the other languages (Italian anf French tested).
> > >>>
> > >>> The DISTINCT 3065 thing seems a common one:
> > >>>
> > >>> In French forum:
> > >>> Erreur générale
> > >>> SQL ERROR [ mysqli ]
> > >>>
> > >>> Expression #1 of ORDER BY clause is not in SELECT list,
> > >>> references
> > >>> column 'forumaoo_fr.t.topic_last_post_time' which is not in
> > >>> SELECT list;
> > >>> this is incompatible with DISTINCT [3065]
> > >>>
> > >>> And in Italian:
> > >>> SQL ERROR [ mysqli ]
> > >>>
> > >>> Expression #1 of ORDER BY clause is not in SELECT list,
> > >>> references
> > >>> column 'forumaoo_it.t.topic_last_post_time' which is not in
> > >>> SELECT list;
> > >>> this is incompatible with DISTINCT [3065]
> > >>>
> > >>> Hagar
> > >>>
> > >>>
> > >>> Le 04/01/2018 à 21:33, Hagar Delest a écrit :
> > Hi,
> >
> > Since the move, we noticed that when performing an advanced
> > search
> > that should display the results as topics, then we get an error:
> >
> > General Error
> > SQL ERROR [ mysqli ]
> >
> > Expression #1 of ORDER BY clause is not in SELECT list,
> > references
> > column 'forumaoo_en.t.topic_last_post_time' which is not in
> > SELECT
> > list; this is incompatible with DISTINCT [3065]
> >
> > SQL
> >
> > SELECT DISTINCT SQL_CALC_FOUND_ROWS t.topic_id FROM
> > phpbb_en_topics t,
> > phpbb_en_posts p WHERE MATCH (p.post_subject, p.post_text)
> > AGAINST
> > ('+solved ' IN BOOLEAN MODE) AND t.topic_id = p.topic_id ORDER
> > BY
> > t.topic_last_post_time DESC LIMIT 250
> >
> > The same search is fine when set to display results as posts.
> >
> > Could you have a look please?
> > Thanks
> >
> > Hagar
> >
> >
> > Le 04/01/2018 à 03:30, Chris Lambertus a écrit :
> > >> On Jan 1, 2018, at 2:24 PM, Chris Lambertus
> > >> wrote:
> > >>
> > >> Hi folks,
> > >>
> > >> At 0100 UTC on Thursday January 4th, I will be moving the
> > >> OpenOffice
> > >> PHPBB forum databases to a new server. The forums will be
> > >> offline
> > >> during this process, and is expected to take about 2 hours.
> > >>
> > >> -Chris
> > >> ASF Infra
> > >>
> > >>
> > >
> > > Hi all,
> > >
> > > This move has been completed. Spot checks on the forums look
> > > good.
> > >
> > > -Chris
> > >
> >
> > >>>
> > >>>
> > >>>
> -
> > >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > >>> For additional commands, e-mail: dev-h...@openoffice.apache.org
> > >>>
> > >>>
> > >
> >
> >
>
Re: Board report proposal, please comment before April 5.
On Sun, Apr 05, 2015 at 11:49:44AM +0200, jan i wrote: >... > I have never thought or said this was about my person, it has nothing to do > with my person. > It has to do with the free will of a community versus discussions on > private list outside the reach of the community. As the AOO VP, it is your responsibility to bring concerns from those private lists, back to this public list/community. The Foundation does not participate on this mailing list, but it *does* have concerns and feedback. Thus, the Foundation appoints VP to act as the go-between, and expects the VP to perform that role as a liaison. > Fact is, that I have received multiple "suggestions" on the private board > list to implement some of your wording or similar wording, these mails (not > from you, but a reaction to your mail) ignores the fact, that there was > consensus in the community to submit the report. Incorrect. None of the responses even implied such a problem. Absent such, and as *usual* for the board mailing list, it was absolutely recognized this was the AOO report submitted by the PMC and its community. Some edits/suggestions were made. That is all. Nothing more. > For reference, your wording was in a mail to a private list, so only the > PMC has seen the content. Yes. > I have on the private board list rejected to change the wording, without a > public discussion > on this list. That's your prerogative. For myself, I have great concern about how you *carried* those concerns back to the community. Your job as VP is to bring concerns from the Foundation to the community, and to bring community concerns to the Foundation. Doing a full-reset on the report isn't constructive. > > Please lets not over-react to what was just some helpful notes. > > I actually took your mail positively, and based on your mail started a > discussion with the PMC, if we should change the wording. I would have > wished you had participated in the > original public discussion. The Foundation does not participate on all dev@ lists. You should expect feedback from all corners, and from people who do not participate here. Again: your job is to bring *that* feedback back here for further contemplation. It is not reasonable to expect all Directors and ASF Members and others to participate here, to formulate your report to the Board. But you *should* expect those others to respond to a submitted report. They will see it when the report gets submitted, and will review it at that time. > But the mails that followed suggesting that I should change the report are > an, to me, unacceptable attempt to bypass the community. Nobody suggested you change it unilaterally. Stop mischaracterizing the suggestions. Again, as VP your job is to bring those concerns, suggestions, and edits to the community if you feel that is proper. Nobody told you what to do. You made the choices on pulling the report, and (mis)characterizing the feedback. > Thanks for presenting your very relavant views in public, and let us get > consensus on a text > acceptable both to this community and the readers of the board list. You do not have to do anything for the readers of the board list. That is your mistake. And it was only a few people. The board list has over a hundred people on it. Your report needs to come from the community, and be reported to the Board. That is quite simple. The Board accepts 99% of the reports submitted. There are some that get rejected (like the one you've left in the agenda right now). But there are also MANY that receive feedback and get updated before the Board reviews/discusses them. So. Be like those other folks. Take some feedback. Discuss it. Update. -g - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Board report proposal, please comment before April 5.
On Sun, Apr 05, 2015 at 02:17:01AM +0100, Simon Phipps wrote: >... > The report should stand as-is rather than be voided by a private request > that seems to fly in the face of the public evidence. Agreed, Simon. Jan "voided" the report after feedback from (3) individuals, speaking as such. The only entity which can direct the PMC is the Board, and it certainly didn't speak up. This was Jan's choice/decision. -g - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Board report proposal, please comment before April 5.
On Sun, Apr 05, 2015 at 02:37:46AM +0200, jan i wrote: >... > Background is that after the report was submitted, a ASF Member (not board > member and not part of our community) > felt that I as new AOO chair, had formulated the report too negative and > against the wishes of the community "against the wishes of the community" is simply untrue. That was never said. Else-thread, Gavin has said he hoped for a more positive report that wouldn't scare people away. ... at no point, in his original message, or any other message, did people say the report was not representative of the AOO community. Totally false. Then, you effectively deleted the Board report out of the meeting agenda, pending further discussion here. That is certainly the wrong path. IMO, the most appropriate response would be to just bring the concerns about positive/negative, and then discuss modifications. Lastly: the submission deadline is April 10. The Board is likely to postpone its meeting by a week, giving the AOO PMC yet another week to (re)submit a report. -g - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Serf 1.2.1 has been released
Hello everyone! We have just made a release of serf 1.2.1. This fixes a number of bugs, including a pretty bad bug in digest authentication on a single, shared connection (issue 102). You can see all the changes at: http://serf.googlecode.com/svn/tags/1.2.1/CHANGES Download details are at: http://code.google.com/p/serf/downloads/list Direct links: http://serf.googlecode.com/files/serf-1.2.1.tar.bz2 SHA1: f65fbbd72926c8e7cf0dbd4ada03b0d226f461fd http://serf.googlecode.com/files/serf-1.2.1.zip SHA1: f0617809c13539be601aa433a03f365d44c78b5c Please report any problems to serf-...@googlegroups.com Cheers, -g - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
Sarcasm accepted. Thank you. On Thu, Apr 04, 2013 at 02:54:41PM -0400, Rob Weir wrote: > Sorry for talk posting. I get it now. If AOO is more secure than other > Apache projects than this may give the impression that the other projects > are less secure because they do not take these precautions. No project can > be better than others since that implies some are worse. So any attempt to > improve must be resisted since it reflects poorly on the projects that > don't. > > I apologize for not noticing this before. I understand completely. It is > a very human reaction. I guess I'll just wait for the time to come for > other projects to figure this out, through whatever painful lessons await > them, so we can then move forward together, at the same pace. > > -Rob > > > On Thu, Apr 4, 2013 at 2:33 PM, Rob Weir wrote: > > > > > > > > > On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein wrote: > > > >> Also, let me say one more thing: > >> > >> This notion of creating divisions among committers ... it is "solving" > >> a problem that has never occurred here. > >> > >> NEVER. OCCURRED. > >> > >> > > So frickin' what? That is entirely irrelevant. My house has never burnt > > down either, but I still don't leave open flames around unattended. In > > fact you might think this is naive view, but avoidance of such risks might > > even be correlated with lack of house fires. Hmmm > > > > > > > >> In the Foundations's 14+ year history, we have never seen a trojan > >> commit. Our servers have been compromised a handful of times. When we > >> were back on CVS, we even had to audit source control to verify no > >> trojan injection. But we have NEVER had a case of a malware commit. > >> > >> > > Again, that proves nothing. I'm sure the first time apache.org was > > rooted that it had never happened before either, right? > > > > > > > > > >> So back to IMO: dividing and partitioning and separate privilege > >> levels... there is no reason. It creates a social problem to "solve" a > >> non-existent issue. Net result: more problems. > >> > >> > > > > Greg, we already do this. Does every ASF Member have credential for Infra > > root? Does ever ASF Member have access to legal-private mailing list. No. > > No. We even do this in the AOO project, with separate authz for > > openoffice-security, which by the way also includes an SVN tree. > > > > Anyone who thinks this is a question of dividing and privilege is > > expressing a knee-jerk reaction, without thinking of the risks. We should > > avoid regurgitating platitudes. Remember, we're talking about people who > > have never committed code, who don't even know C, who are not even > > subscribed to the dev mailing list, and in some cases have never ever > > posted to our mailing lists. They signed up in with the podling in July > > 2011 and then were never heard of again. You make an extremely weak > > argument to pontificate about "privilege" here. > > > > The risks are real. High profile open source projects attract these kinds > > of attacks. There are those who know it, and those who don't know it yet. > > > > A good read: > > http://www.securityweek.com/linux-source-code-repository-kernelorg-gets-hacked > > > > As for those who think that casual review of commit messages will review > > any attack, that is a dangerously naive few. We should not expect an > > attack to be in a filed called trojan.c with comments and clear logic > > explaining what the code does. Any hacker with a clue would send a patch > > backed by a reasonable defect report in Bugzilla that would be innocuous to > > casual inspection. All you need is a buffer or stack overwrite in a > > well-placed area to cause the problem. This might even be done in two > > stages, spread out over time, so the impact is not detectable without > > looking at the pieces together. > > > > Now if someone did that in the name of an active committer it would be > > *immediately* detected. "WTF!? I didn't check that in!" But when done in > > the name of an unactive committer it would be less likely to be noticed for > > what it is. We might check twice, but that doesn't mean we'd catch all or > > even most deliberate attacks. But whatever detection rate we would have > > there it would be far less than the presentation rate for not having > >
Re: Proposal: Improve security by limiting committer access in SVN
Your proposal to alter the community structure is premised upon a
strawman risk. First, that it would occur. Second, that it wouldn't be
noticed. Third, that it would find its way into users' hands.
In the past, the Foundation has *explicitly* said that we would accept
a certain level of risk to maintain our communities.
I find your strawman at a level even *lower* than the scenario that
I'm thinking about(*).
If you're worried about stale committers suddenly inserting trojans,
then just use 'svn log' to find those outliers. No need to create
division within the community. Run a simple histogram. There are many
solutions to your purported attack vector, than to divide into groups.
Cheers,
-g
(*) a certain large company's lawyer (ahem) was trying to scare the
ASF ("the risk!!") into adopting certain procedures; we shut her down
On Thu, Apr 04, 2013 at 02:33:12PM -0400, Rob Weir wrote:
> On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein wrote:
>
> > Also, let me say one more thing:
> >
> > This notion of creating divisions among committers ... it is "solving"
> > a problem that has never occurred here.
> >
> > NEVER. OCCURRED.
> >
> >
> So frickin' what? That is entirely irrelevant. My house has never burnt
> down either, but I still don't leave open flames around unattended. In
> fact you might think this is naive view, but avoidance of such risks might
> even be correlated with lack of house fires. Hmmm
>
>
>
> > In the Foundations's 14+ year history, we have never seen a trojan
> > commit. Our servers have been compromised a handful of times. When we
> > were back on CVS, we even had to audit source control to verify no
> > trojan injection. But we have NEVER had a case of a malware commit.
> >
> >
> Again, that proves nothing. I'm sure the first time apache.org was rooted
> that it had never happened before either, right?
>
>
>
>
> > So back to IMO: dividing and partitioning and separate privilege
> > levels... there is no reason. It creates a social problem to "solve" a
> > non-existent issue. Net result: more problems.
> >
> >
>
> Greg, we already do this. Does every ASF Member have credential for Infra
> root? Does ever ASF Member have access to legal-private mailing list. No.
> No. We even do this in the AOO project, with separate authz for
> openoffice-security, which by the way also includes an SVN tree.
>
> Anyone who thinks this is a question of dividing and privilege is
> expressing a knee-jerk reaction, without thinking of the risks. We should
> avoid regurgitating platitudes. Remember, we're talking about people who
> have never committed code, who don't even know C, who are not even
> subscribed to the dev mailing list, and in some cases have never ever
> posted to our mailing lists. They signed up in with the podling in July
> 2011 and then were never heard of again. You make an extremely weak
> argument to pontificate about "privilege" here.
>
> The risks are real. High profile open source projects attract these kinds
> of attacks. There are those who know it, and those who don't know it yet.
>
> A good read:
> http://www.securityweek.com/linux-source-code-repository-kernelorg-gets-hacked
>
> As for those who think that casual review of commit messages will review
> any attack, that is a dangerously naive few. We should not expect an
> attack to be in a filed called trojan.c with comments and clear logic
> explaining what the code does. Any hacker with a clue would send a patch
> backed by a reasonable defect report in Bugzilla that would be innocuous to
> casual inspection. All you need is a buffer or stack overwrite in a
> well-placed area to cause the problem. This might even be done in two
> stages, spread out over time, so the impact is not detectable without
> looking at the pieces together.
>
> Now if someone did that in the name of an active committer it would be
> *immediately* detected. "WTF!? I didn't check that in!" But when done in
> the name of an unactive committer it would be less likely to be noticed for
> what it is. We might check twice, but that doesn't mean we'd catch all or
> even most deliberate attacks. But whatever detection rate we would have
> there it would be far less than the presentation rate for not having
> authorization enabled at all. The prevention rate there is 100%
>
> Regards,
>
> -Rob
>
>
>
>
>
> > Cheers,
> > -g
> >
> > On Thu, Apr 04, 2013 at 05:59:31PM +, Greg Stein wrote:
> > > Speaking as one of those "old-hands", Denni
Re: Proposal: Improve security by limiting committer access in SVN
Also, let me say one more thing: This notion of creating divisions among committers ... it is "solving" a problem that has never occurred here. NEVER. OCCURRED. In the Foundations's 14+ year history, we have never seen a trojan commit. Our servers have been compromised a handful of times. When we were back on CVS, we even had to audit source control to verify no trojan injection. But we have NEVER had a case of a malware commit. So back to IMO: dividing and partitioning and separate privilege levels... there is no reason. It creates a social problem to "solve" a non-existent issue. Net result: more problems. Cheers, -g On Thu, Apr 04, 2013 at 05:59:31PM +, Greg Stein wrote: > Speaking as one of those "old-hands", Dennis is absolutely spot-on. > > Partitions, barriers, sub-groups... I call those "divisive" mechanisms > which serve to divide the community. Such divisions are rarely needed. > > As Andrea points out, in Subversion's 13 year history, we have only > *requested* people observe certain fences. We have never had a > problem. We have never had to take sanctions. A stray commit here and > there? Sure, it has happened, with the best intent, so we just point > out that they need a bit more caution. No harm done. > > Back to Dennis' point: the solution here is proper review of the > commits that occur. (IMO) NOT a way to *exclude* or to *limit* the > potential contributions of others. > > Cheers, > -g > > On Thu, Apr 04, 2013 at 09:23:39AM -0700, Dennis E. Hamilton wrote: > > In previous generations of this kind of discussion, the ASF old-hands will > > point out that the social process works quite well, folks don't do commits > > unless they feel qualified to do so, and it is often the case that > > committers will request RTC (i.e., submit patches rather than update the > > SVN) in contributing where they are not experienced or don't consider > > themselves expert. > > > > At the ASF this appears to be one of those, "if it is not broken, don't fix > > it." > > > > There is still the concern about stolen credentials used to perform > > undetected malicious acts. If the oversight that the project naturally > > brings to bear on visible changes to the code base is insufficient, I think > > the problem is greater than there being a possible exploit of that > > inattention. Mechanical solutions may be part of the disease, not the cure > > [;<). > > > > - Dennis > > > > -Original Message- > > From: Andrea Pescetti [mailto:pesce...@apache.org] > > Sent: Thursday, April 04, 2013 08:57 > > To: dev@openoffice.apache.org > > Subject: Re: Proposal: Improve security by limiting committer access in SVN > > > > Dave Fisher wrote: > > > Let's focus only on adding one new authz list for the code tree. > > > Call it openoffice-coders and populate it with those who HAVE any > > > commit activity in the current code tree. > > > > I checked feasibility with Infra. Summary: > > > > 1) LDAP is not the solution. Rule it out. > > > > 2) The only possible solution would be an authz rule like suggested by > > Dave here; however, Infra quite discourages it, mainly for maintenance > > reasons. This leads me to think we would need some good justifications > > for implementing this. > > > > 3) If the justification is security, then there are other privileges to > > monitor. Namely, every committer has shell access to people.apache.org, > > authenticated access to the Apache SMTP server and CMS privileges for > > the openoffice.org website, including publish operations. > > > > For the record, the Subversion project has complex rules like Rob > > pointed out; but it's only a "social enforcement", i.e., all committers > > respect those limitations by their own choice; if you look at the > > technical level, every committer (all Apache committers) can commit code > > to the Subversion subtree. > > > > Regards, > >Andrea. > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
Speaking as one of those "old-hands", Dennis is absolutely spot-on. Partitions, barriers, sub-groups... I call those "divisive" mechanisms which serve to divide the community. Such divisions are rarely needed. As Andrea points out, in Subversion's 13 year history, we have only *requested* people observe certain fences. We have never had a problem. We have never had to take sanctions. A stray commit here and there? Sure, it has happened, with the best intent, so we just point out that they need a bit more caution. No harm done. Back to Dennis' point: the solution here is proper review of the commits that occur. (IMO) NOT a way to *exclude* or to *limit* the potential contributions of others. Cheers, -g On Thu, Apr 04, 2013 at 09:23:39AM -0700, Dennis E. Hamilton wrote: > In previous generations of this kind of discussion, the ASF old-hands will > point out that the social process works quite well, folks don't do commits > unless they feel qualified to do so, and it is often the case that committers > will request RTC (i.e., submit patches rather than update the SVN) in > contributing where they are not experienced or don't consider themselves > expert. > > At the ASF this appears to be one of those, "if it is not broken, don't fix > it." > > There is still the concern about stolen credentials used to perform > undetected malicious acts. If the oversight that the project naturally > brings to bear on visible changes to the code base is insufficient, I think > the problem is greater than there being a possible exploit of that > inattention. Mechanical solutions may be part of the disease, not the cure > [;<). > > - Dennis > > -Original Message- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Thursday, April 04, 2013 08:57 > To: dev@openoffice.apache.org > Subject: Re: Proposal: Improve security by limiting committer access in SVN > > Dave Fisher wrote: > > Let's focus only on adding one new authz list for the code tree. > > Call it openoffice-coders and populate it with those who HAVE any > > commit activity in the current code tree. > > I checked feasibility with Infra. Summary: > > 1) LDAP is not the solution. Rule it out. > > 2) The only possible solution would be an authz rule like suggested by > Dave here; however, Infra quite discourages it, mainly for maintenance > reasons. This leads me to think we would need some good justifications > for implementing this. > > 3) If the justification is security, then there are other privileges to > monitor. Namely, every committer has shell access to people.apache.org, > authenticated access to the Apache SMTP server and CMS privileges for > the openoffice.org website, including publish operations. > > For the record, the Subversion project has complex rules like Rob > pointed out; but it's only a "social enforcement", i.e., all committers > respect those limitations by their own choice; if you look at the > technical level, every committer (all Apache committers) can commit code > to the Subversion subtree. > > Regards, >Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Serf 1.2.0 has been released
Hi all, I'm pleased to announce the serf 1.2.0 release! This release contains many robustness fixes, especially around flaky and problematic connections. The CHANGES file is located at: http://serf.googlecode.com/svn/tags/1.2.0/CHANGES Download details are at: http://code.google.com/p/serf/downloads/list Direct links: http://serf.googlecode.com/files/serf-1.2.0.tar.bz2 SHA1: 30b29bd9214d50887abcc20cf82096aaaf5d1d61 http://serf.googlecode.com/files/serf-1.2.0.zip SHA1: 07112bb7f715e1ec472f190c7b3051189969bba7 Please report any problems to serf-...@googlegroups.com Cheers, -g
Re: Proposal: How we should handle committer vetos and reverts in the future
On Fri, Feb 15, 2013 at 09:11:13AM -0500, Rob Weir wrote: > On Fri, Feb 15, 2013 at 8:57 AM, Rob Weir wrote: > > On Fri, Feb 15, 2013 at 8:45 AM, Greg Stein wrote: > >> On Thu, Feb 14, 2013 at 05:31:43PM -0500, Rob Weir wrote: > >>> Obviously the changes to Calc's POWER() function did not go well. > >>> > >>> IMHO, we need to better respect the rare but powerful veto option that > >>> committers have: > >>> > >>> http://www.apache.org/foundation/glossary.html#Veto > >>> > >>> When a committ is vetoed, it should be reverted quickly. Remember, a > >> > >> No. This is flat out incorrect. > >> > >> A veto means you cannot *ship* with that change in there. It can stick > >> around as long as necessary, but must eventually be pulled out when > >> the code is shipped. > >> > > > > > > If this is true then you have a Foundation document which is incorrect > > and needs to be changed, since it is totally out of synch with what > > you are saying: Not surprised. > And Greg, just to be perfectly clear and to avoid any misunderstanding > here, I'm not arguing against your interpretation. If that is the > consensus view then I'm happy to adopt it as my own. I'm just > pointing out that you have a prominent page on the website that, to > the uninitiated, appears to say something entirely different. Phrases > like "forces it to be reverted" and "may not be overridden nor voted > down" are quite strong statements. Any change can be vetoed at any time. There is no statute of limitations, except for making a release. (http://s.apache.org/j4) Thus, "bad" code can sit around in version control for a very long time. The "forces it to be reverted" is in reference to making a release. Obviously, the community doesn't want to wait that long. Ripple effects can make it hard to revert the change later. This is why you start the discussion and come to consensus on how to proceed. In my experience, "proceed" usually means additional changes to address the concerns raised. The only time "revert" has ever been the solution is when somebody has added huge new chunks of code that the community doesn't agree with [in terms of direction]. There is quite a bit of history in the httpd project discussing what "veto" means, and how to handle them. I summarize all those years with the simple phrase, "veto means a discussion is needed". Cheers, -g
Re: Proposal: How we should handle committer vetos and reverts in the future
On Thu, Feb 14, 2013 at 05:31:43PM -0500, Rob Weir wrote: > Obviously the changes to Calc's POWER() function did not go well. > > IMHO, we need to better respect the rare but powerful veto option that > committers have: > > http://www.apache.org/foundation/glossary.html#Veto > > When a committ is vetoed, it should be reverted quickly. Remember, a No. This is flat out incorrect. A veto means you cannot *ship* with that change in there. It can stick around as long as necessary, but must eventually be pulled out when the code is shipped. There is no "quickly" about it. A veto means a start of a *discussion*. The discussion can end up with at least a few outcomes: * the committer realizes the problem, agrees, and reverts * the committer understands the (technical) concern, and modifies the change to address that concern * the veto-er learns more about the change and withdraws the veto In all of these cases, there is no mandate to revert. The veto has never in the course of the Founddation meant "revert now". It has meant "we need to talk about it; I have some concerns". >... > If the original coder is willing and able to revert quickly, then > great. But anyone, including the veto'er can do this. It is not No. This is anti-social. Given that there are multiple possible outcomes of the discussion, somebody deciding *unilaterally* to revert the change is doing just that: putting their decisions above those of the group's consensus. The correct result is to generate consensus on why the change was (technically) problematic, and to arrive at a solution. In most cases, the result is to make additional changes to resolve the technical problem. Taking a step back is *rarely* the answer, and an individual who unilaterally makes a decision for the group is being anti-social. >... > It is very likely that the person whose changes were vetoed will not > like the veto or the revert. That is quite natural. We all have > egos. None of us like having our changes rejected. We all have our > egos wrapped up in our code. That is why we cannot rely on the > original coder being the one to revert. We don't want to turn this > into a battle of wills between the person who made the change and the > person(s) who vetoed it.Put egos aside. A veto is not the > opportunity to escalate the argument. A veto is an opportunity to > isolate the controversial code where both sides can calmly discuss it, > knowing that there is no longer immediate concern in the main code. > And reversion is SVN is a simple mechanical act. It does not require > anyone special to do it. Any committer can do it. And this is not a "both sides" issue, but a community issue. A discussion starts. And the original committer should be the one to decide, based upon the discussion result. You talk about ego, and we all have them. The answer is to work with that fact, and come to a mutual decision. Not to slap another's ego in the face with unilateral decisions to alter the work that a person is attempting to perform. >... > The point of a veto and a quick reversion is to return the code base > quick to a state where it does not contain controversial changes in > it. That is NOT the point of a veto. A veto is "don't ship with that". The corollary actions are very, very different from what you suggest. About the *only* time when somebody should revert another's is when the build system becomes broken. That shuts down the entire community. Note: I'm not talking about test failures. Introducing a failure does not prevent the community from acting. But build breakages certainly can (at least, on default configurations; if the breakage is with an obscure config, then it could possibly be left in for a day or two to work out a proper solution). Joe pointed out the standard 72 hours. Shoot for that if you see some kind of build breakage, but if it is just too horrific, and it appears the committer has gone away for a while, then do the minimum possible to restore the build. Use a proper log message, and alert the original committer what you have done. Cheers, -g
