Re: [pkg-go] Bug#856139: certspotter: long description advertises commercial service
On Fri, Aug 11, 2017 at 08:03:09AM -0400, Wouter Verhelst wrote: > If a free software implementation of the remote service exists that a > package can work with, then it can remain in main. If not, it cannot. There are no free software server-side implementation of e.g. the ICQ protocol, as far as I know, but multiple client-side implementations in main. For that matter, there is no free software server-side implementation of QUIC, so I guess by that rule, Chromium should be in contrib as well. Pretty sure that there isn't any kind of consensus for any of that. As for certspotter, the conversation has derailed quite a bit -- in part because Jonas forwarded this to debian-project while stripping almost the entirety of my reply on the bug, then stripping again all of the context when days later, he started a new thread from scratch on debian-devel. Not cool. To clear things up: - certspotter is free software, and is used to check Certificate Transparency logs, notifying the user if any certificates in the wild have been observed matching a domain of theirs. - The author of certspotter also runs the SSLMate as a commercial offering, which hosts a version of certspotter for anyone to use. It's free for up to 5 domains, then charging for more, for presumably larger enterprises (but these can still opt to run it themselves, using certspotter). The SSLMate website, in the menu under "Cert Spotter", has "Pricing", "API", "Open Source", in that order, with the latter pointing to the GitHub page of certspotter. - People called SSLMate "non-free" and objected to the certspotter description pointing to it. While it is true that it is non-free to some extent, as the web dashboard and code that glues certspotter to it isn't free (AFAIK), the most interesting and complicated part of it (a pretty flexible CT log client) is. - certspotter does not connect to SSLMate in any way. certspotter (either the one locally installed, or the one run by SSLMate) connect to the various CT Logs run by CAs, Google etc. In fact, it connects to the same CT log servers that Chromium does. - Certificate Transparency is an IETF protocol (RFC 6962) and is implemented, as a client, by both Chromium and Firefox. Google has released a a number of freely licensed client libraries, as well as their reference implementation of the CT Log server. Even if the blanket rule that Wouter mentioned existed, certspotter would satisfy it. - I don't have any personal or business connection to SSLMate or certspotter, other than using the software and maintaining the package. I haven't communicated with my upstream about this issue either and my comment on the bug report are just my views. I just want to be fair to a nice upstream, who has graciously released part of their business as free (as in speech and as in beer) software, for anyone to use instead of using their service. I read both of the threads so far (sadly, as most of it was offtopic and a waste of precious DebCamp/DebConf time) and from all the suggestions, I really appreciated and valued Chris Lamb's response about dropping the "requires zero setup" bit. I intend to drop that part on the next upload, whenever that happens. Regards, Faidon
DSA Team Meeting minutes, 2013-10-11
Present: luca (Luca Filipozzi) paravoid (Faidon Liambotis) weasel (Peter Palfrader) zumbi (Héctor Orón Martínez) Mithrandir (Tollef Fog Heen) zobel (Martin Zobel-Helas) sgran (Stephen Gran) Ongoing project update o debian.org mail move status (tfheen, sgran) - big move is done, cleanup work is needed, esp. to reduce the number of mail-receiving hosts - unsure at this point if big services like ftp-master draghi will stop accepting mail directly; starting with easier ones such as gobby.d.o. Processing mail locally but not being open to the internet is the agreed middle ground. o openstack (sgran) - Package version evaluation complete. Havana trial at work underway. d.o deployment work plans started o disks for beethoven (weasel, zobel) - TK says they can't find any fault with the system; blame it to our SATA disks not being enterprise-grade. - Peter installed the box and it crashed again, with the controller going AWOL - This has consumed too much time; agreement to replace beethoven early and reuse the disks. - ACTION: zobel to look for beethoven replacement (rt #4724) o disks for bytemark (tfheen) - stalled, on the backburner due to other projects - backup disks are getting full; needs reprioritisation - ACTION: tfheen to do disks for bytemark o ns4 to move away from orff (weasel) - no progress o CDN plan (tfheen) - DPL wants a larger discussion - ACTION: tfheen to send an email to debian-project; Lucas to help o ARM OOB status (zumbi) - we now have serial console (via console servers) to the arm machines hosted at ynic and arm. - we don't have remote power; this is coming eventually. o ARM Calxeda nodes plan/roadmap (zumbi) - nothing new, waiting for the ARM sprint next month (14-17 Nov) o Shipping of cyclades console servers - we now have a console server in Vienna for the mipsels and we have remote power for them. - one of the console servers is in Darmstradt but not in man-da yet. ETA: one month at most. o debdelta, codesearch (tfheen) - no progress o franck and carepacks (luca, zobel) - softchoice unresponsive - ACTION: decide what we want, tell SPI treasurer to buy it from CDW o SSO status (zobel) - no progress. Sprint planned for January. o New UD status (luca) - plan to roll out in December - ACTION: luca to reply to Olivier Berger o SSL certificates - no reply from Gandi regarding billing challenge (root cause: they only handle CC well) - ACTION: luca to ping Gandi regarding billing mechanism or 'ssl certs in lieu' o GRnet hardware purchases - GRnet has recommitted to the rack space they offer to Debian but want to move Debian equipment to new DC - ACTION: paravoid to discuss timing / planning for the move; maybe we buy new equipment for the new DC o HP AllianceOne for Greece - our contact in HP@EU has changed position; need to find new contact - ACTION: paravoid will contact tbm - ACTION: paravoid will contact HP reseller that GRnet uses o MAN-DA hardware purchases - ACTION: zobel will coordinate purchases with those needed for DG-i (to replace beethoven) o ries disk shipping (luca) - in progress; no response from ECE yet - ACTION: luca to get this sorted today o small items budget - discussed on devel, went to d-d-a, done (thanks lucas) o alioth hw - bytemark blade to be used. no other blockers o service guidelines (zobel) - no progress o archive.org - ACTION: luca to ping them o stabile - ACTION: luca to source new controller cards o single source of truth - ACTION: luca to look at after ud roll-out (http://ralph.allegrogroup.com/) Open items o broken HW that needs somebody to deal with it (there should be tickets): - saens disk o ravel move Next Meeting: 2014-11-08 1430Z -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131014143426.gb26...@dewey.void.home
Re: Introducing http.debian.net, Debian's mirrors redirector
Hi, On 06/21/12 23:32, Raphael Geissert wrote: After several iterations to solve problems related to Debian's mirrors network, I am happy to announce a fully-functional solution that solves many of the shortcomings of previous iterations: http://http.debian.net I have two objections if I may: a) I think that the http.debian.net name is too generic and IMHO an abuse of the /intent/ of debian.net domains. Even though debian.net is being run as a first-come first-serve service, we are members of the same project and we shouldn't just pick catchy generic domains just because we can. (I had similar objections over e.g. git.d.n, among many others). b) You announced this to d-d-a and your blog/planet. However, I believe that there are readers of those media -esp. planet- that are not that much involved into Debian practices and may not know the distinction between debian.org debian.net. I think people announcing such services publically should be careful and note that it's a personal service of theirs, rather than the project's. I'm not suggesting that you mislead people intentionally but rather that I would like you to be more explicit in the future -- or the present, e.g. in http.d.n's homepage). Thanks, Faidon P.S. The above views are my own, not DSA's or anyone else's. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe3abf4.5010...@debian.org
Re: Diversity statement for the Debian Project
On 03/23/12 15:28, Francesca Ciceri wrote: So, I wrote a draft - mainly based on the one [4] created for Ubuntu by Matt Zimmerman with the help of Mary Gardiner, Valerie Aurora and Benjamin Mako Hill - and I'd like to propose it to the DPL to be official published. Thanks for doing this. However, I'd prefer it if we acknowledged and published this by way of a General Resolution. It's not that I don't think the DPL is empowered to publish it without a GR but I think that a) it feels better to me to have statements that express the whole project acknowledged and voted on by everyone b) it will give the whole welcoming everyone/not discriminating statement more weight. Best regards, Faidon -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f6d0793.3010...@debian.org
Re: On terminology
Stefano Zacchiroli wrote: On Sat, Jul 03, 2010 at 12:14:03AM +0300, Faidon Liambotis wrote: Am I the only one who has trouble -and getting laughed at- whenever I try to explain these to potential contributors? Can we _at least_ rename the NM process to be indicative of what it is? Seconded. OK, I see a lot of people seconding this (incl. the DPL) and noone objecting, but I'm not really sure what's the procedure (and the actions needed) to get this changed. Zack, are you going to coordinate this with your DPL hat? If there's need for some dumb manpower, I'd be happy to help. Cc'ing the NM frontdesk which (I guess) is the appropriate team. Regards, Faidon -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c320674.3080...@debian.org
Re: debian-private declassification team (looking for one)
On 25/06/2010 07:43 μμ, Russ Allbery wrote: I would welcome a new GR to rescind the previous one and revert d-private to what it's always been: private. That way we can stop worrying about the whole issue and we will no longer run the risk of making things public that their authors do not want to be made public. +1. Then people wouldn't have to keep putting this is private in messages and could just assume it. If there aren't enough volunteers to do the work anyway, we're wasting low levels of energy making people aware of this right now. I agree as well. There's no point in making promises we cannot fulfill; if anything, it makes us look bad. We should just accept the fact that noone will ever re-read a big pile of old, heated, discussions and vacation notices just to publicize parts of them. The time plus the risk of making a mistake (and the fallout of that) just doesn't worth it. Regards, Faidon -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c24f9ce.8070...@debian.org
Re: PTS subscription exposure
Gerfried Fuchs wrote: For the same reason I don't play into facebook's hand with handing them all the linking informations they would like to know (even if some people seem to be personally offended when not being linked). People do contact random people that they find being attached to some package, even remotely. A clean example: I did the security upload for dokuwiki to backports because adn had some issues with his systems. Now random people come along and ask for this and that feature improvement and for sponsoring uploads of newer version, where I just were interested in closing the security issue for backports users in the first place. Νever happened to me but fair enough. Other people might have other reasons, and even if one can't see them doesn't mean that they aren't valid nor aren't there. It's even a bit depressing to actually have to argument *why* one wants to keep their privacy - people all around the world brag around with the nothing to hide slogan for breaching others people's privacy. Sure, I can't argue with that. If you feel that it violates your privacy then it probably does. Nevertheless, I think it's useful to the discussion to refer to some real-world scenarios on how it affects people and be more specific about the privacy problems. Thanks for sharing. Regards, Faidon -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b8e5f2a.9060...@debian.org
Re: PTS subscription exposure
Gerfried Fuchs wrote: This is IMNSHO a serious violation and breach of privacy. I understand the privacy concerns and not liking the fact that someone made some data public that weren't explicitelly marked as such. However, could you please bear with me for a moment and try to explain why you wouldn't want anyone to know your PTS subscriptions? Thanks, Faidon -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b8d8b65.4010...@debian.org
Re: [RFH] ferm integration into dsa-puppet.git
Martin Zobel-Helas wrote: Your mission, if you choose to accept it, is to provide us with a new dsa-puppet git branch with a module ferm that we can roll out to all our hosts. It might want to use information from the other puppet modules like apache2_security_mirror or buildd to decide which incoming traffic should be allowed. DSA will of course provide you with all necessary further information. I have something similar running over at work and I'd be happy to provide code^Wpuppet definitions for that. Feel free to provide me with any other requirements. Regards, Faidon -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re-thinking Debian membership - take #1: inactivity - getting implemented
Stefano Zacchiroli wrote: In the past few days I've been in touch with Christoph Berg as a DAM representative, which has been implementing the inactivity proposal starting from the sample scripts of [1]. Then, DAM also had a first run of the inactivity test (i.e. 2 years without neither an upload nor a vote). Given that it was the first run, instead of directly removing the resulting account, DAM preferred to have a WAT run [2] on the accounts resulting from the inactivity test. The recent set of WAT-related resignations descended from that. I've been told that in the recent future the removal will become automatic de facto replacing WAT runs. DAM will probably post more details separately when that will happen. That's great! Thanks to everyone involved. BTW, I recall some complaints that WaT runs didn't happen often; there over a hundred people in a needs-wat state in the MIA database without action for months. Has this recently changed? Or is it something that will change with the automatic runs that you speak of? Regards, Faidon -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sourceless but useless: how about ignoring some irrelevant files instead of repackaging?
Steve Langasek wrote: What is the upstream zipfile in question? http://www.greekfontsociety.gr/GFS_DIDOT_TT.zip, which seems to be the right upstream zipfile, contains only the 6 files included in the ttf-gfs-didot orig.tar.gz. http://www.greekfontsociety.gr/GFS_DIDOT_OT.zip (OT=OpenType vs. TT=TrueType that you linked) Is http://www.greekfontsociety.gr/images/Didot%20Specimen.pdf the file in question? I certainly don't see that this would be a reason for a package reject, but I also don't see any reason you would go out of your way to package this if it's not already part of the upstream source. That's the file and it's included in the zipfile above (and no, I wouldn't have tried to package this if it wasn't part of the upstream source) And yes, that was the reason for the rejection. Regards, Faidon -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sourceless but useless: how about ignoring some irrelevant files instead of repackaging?
Steve Langasek wrote:
Sourceless PDF files are not a violation of the Social Contract / DFSG. If
you are having to sink time into finding source for such files, let's put an
end to this - give me the details and I'll propose a GR that reaffirms
what's stated already in our founding documents, that source code is only
mandatory for programs.
Just to get this interesting: I've had packages rejected because of
included sourceless PDFs.
Specifically, ttf-gfs-{-didot,-baskerville,-olga,-porson} on 04/04/2008.
Upstream is including a font specimen with their original tarball =
zipfile. I asked them for the specimen source (like that would do us
any good, being in Adobe Illustrator format et al) but they refused, big
surprise there.
TBH, I can see arguments for both sides.
Regards,
Faidon
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sourceless but useless: how about ignoring some irrelevant files instead of repackaging?
Charles Plessy wrote: in one of the packages I mainatain, upstream left some zlib and ncurses static libraries for Win32 in the source tarball. Without the copy of the zlib and ncurses sources. Alternatively, I can of course ask Upstream to remove the Windows binaries, but how can I convince him that we hurt our users by leaving these files in the Debian source packages, while the sources of zlib and ncurses are actually distributed by Debian together with the sources of his program? You are making the assumption that the source from which those static libraries were built is equivalent to the source that we ship in Debian. This is most probably incorrect: think of different versions, patches or other differences etc. Even if it is now the case, you can't be sure that it will be in the future, when e.g. the source for one of these gets updated or removed entirely from Debian. Not to mention the build-time configuration options -- which, in this case, is certainly different. The requirements of main, and often of upstream licenses, is that the *corresponding* source code must be shipped along the binaries, plus the build system and its configuration (that's certainly the case for the GPLv2). Regards, Faidon -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Steve McIntyre wrote: To be fair, I've not been doing a good enough job of talking with the project as a whole lately. I *have* been talking to a lot of people inside and outside Debian about things in that time, but a combination of a very busy day job and a new girlfriend have been keeping me much quieter than I was planning for. If you want to be fair, you should mention that you have a 2IC for exactly the too busy in real life reason. Regards, Faidon -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DAM and NEW queues processing
Peter Palfrader wrote: On Fri, 26 Jun 2009, Faidon Liambotis wrote: Something is definitely wrong here, IMHO. Maybe it's your assumption or assertion that the only point of NEW is checking the copyright file. It is my assumption that this is the part of NEW that is the most time consuming and causes delays, which is the context of this discussion. Am I wrong? If yes, please explain. Regards, Faidon -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DAM and NEW queues processing
Joerg Jaspert wrote: On 11790 March 1977, Bernd Zeimetz wrote: In my experience, package splits go through in a week or two except in rare situations. That never seemed like a difficult wait to me. Ack. Same for adding debug packages and similar things like soname bumps. Those are all simple additions of binary packages, and yes, NEW does handle them special. They get sorted in front of all the rest, so they are processed early. I don't understand, why pass them through NEW anyway? Why check that specific set (old packages that introduce new binaries) for incomplete debian/copyright? Either a) there's no point for ftp-masters to check those or b) ftp-masters should regularly check a random set of old packages each month, whether they had new binaries or not. i.e. there are tons of packages that had major upstream versions/copyright additions without passing through NEW and there are tons of packages that frequently pass through NEW without any copyright changes whatsoever. Something is definitely wrong here, IMHO. Regards, Faidon -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Developer Status
Joerg Jaspert wrote: We plan to integrate DM more closely into the NM process/system while keeping the spirit of easing entry into Debian for newcomers. At the same time we add a separate track for less-technical contributors. I have to say that I don't like *at all* the way that you're handling this; you posted to d-d-a which implies that this is an announcement, not a proposal and while I know that it is within your powers to do such changes, I think that it is obvious that something like that should be decided (and by that I don't mean overruled) by the body of the DDs and not by any DPL delegate. Also, you admitted that you forgot to clarify who you (plural) are, only to reveal us that you discussed this with other delegates, without further explaining what exactly you mean by that. And from Manoj's reply to the thread (and correct me if I'm wrong) it surely didn't sound like he planned anything with you. It is no secret that discussing stuff is not your style (and I don't mean this as an insult), but please try to bear with us and be more cooperative, both within the project and within specific teams (I'm thinking DebConf organization and sponsorship teams here). I, for one, would support or even propose a GR to overrule you (whoever you might be) as a delegate if you proceed with enforcing this proposal without getting an approval by a GR. Debian Contributor -- Debian Maintainer - Debian Member - Debian Developer Now, regarding your proposal itself, I agree with others that it sounds too bureaucratic, even for Debian. Explaining the differences between maintainer, uploader, Debian Maintainer and Debian Developer to outsiders is hard enough as it is. Please, let's try to Keep It Simple, Stupid. Also, I find it amazing that noone has mentioned all those Alioth -guest users. Am I the only one to think that we should find a way to make Alioth and its users more official and acknowledge that most of those users work for Debian and should be considered members of the project? contributor.debian.org mail Let's not forget that all Alioth users get a mail alias under d.o, we shouldn't consider it _that_ big of a deal. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Stefano Zacchiroli wrote: Can we please wrap part of this thread up by saying that: most of us---i.e., the participants to this thread---would BE OK with passing this proposal *with GR* (after the usual needed discussion time), whereas most of us would NOT BE OK with passing this proposal *without GR*? ACK. Personally, I probably wouldn't vote in favor of this proposal as it is but I would fully respect the outcome if it was decided by the means of a GR, obviously :) I also think that some of the underlying problems that this proposal tries to solve exist and the subject warrants further discussion. I haven't thought about it, but this is a very interesting observation indeed (same on the other on the alioth.d.o mail domain). Still, it is not clear to me how to merge the two proposals. I mean, while I see a partial overlapping among the two infrastructure, I really do not want to get away from alioth project admins the ability to decide upon which accounts are member of their projects. Are you maybe suggesting that alioth account creation should be bound to being a debian contributor? I see more harm than good in something like that ... Yes, I think that should be the case. The fact that with the current proposal this would do more harm than good (with which I perfectly agree) is exactly the reason I find it bureaucratic and overcomplicated. For example, there's nothing special about a DC. No upload rights, no vote rights, no debian.org logins. Just an entry to a 6-month quarantine period to be able to be promoted to a role with actual privileges. And, well, I find it /insulting/ to our current, real, contributors to require them to get an ID check (therefore meeting a DD in real life), go through NM FD, having an AM assigned and answer questions, just to call them what they are! My PoV is that we should *lower* the barrier for new contributors, value and *acknowledge* their contributions and accept them for what they are, (limited) members of the Debian project. I feel that Alioth has served this purpose in a way. This proposal achieves nothing to that effect; quite the opposite, IMHO. OTOH and on an unrelated but relevant to the proposal, I fully agree that we should give the rights to vote and be voted to non-maintainers (artists, translators, documentation writers etc.). e.g. making TS optional NM and tieing it to upload rights would be a simple way to do this but I haven't given any serious thought on this. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
