Re: PHP7.4 When will it be released?
Hi, It won’t. The Debian doesn’t update the PHP version in the stable Debian release. The next major PHP update will happen with next Debian stable (bullseye). Ondrej -- Ondřej Surý ond...@sury.org > On 19 Feb 2020, at 14:44, 李強尼 wrote: > > https://packages.debian.org/search?suite=buster=all=any=names=php7.4 > > Hello > > PHP7.4 > > When will it be released?
Re: are Debian mentors nuts? the DebConf scandal
My guess this is the same individual that is harassing our lists. Maybe we should finally involve lawyers+police and start protecting our community, the Debian community. I am pretty sure that the targeted harassment and release of debian-private archives is punishable by law at least in some jurisdictions. GDPR also comes to a mind. So, I think an official legal action is required now. Ondrej -- Ondřej Surý > On 29 Dec 2019, at 06:34, Matthew Garrett wrote: > > On Sun, Dec 29, 2019 at 04:59:27AM +, Matthew Garrett wrote: >> Just in case anyone's wondering - I checked with Mary-Anne Wolf (who I >> met at Libreplanet some years ago) and she didn't send this mail. >> Someone faked her identity. > > And on the offchance that the subtext here isn't clear, if someone is > using other people's identities to make allegations of inappropriate > behaviour, it's pretty reasonable to conclude that they're not acting in > good faith. Anonymous disclosure doesn't require taking advantage of any > legitimacy or goodwill other community members may have built up. > > -- > Matthew Garrett | mj...@srcf.ucam.org >
Be nice to your fellow Debian colleagues
Hi, the init systemd GR is over and we have reached the results in a democratic way by following Debian Constitution. However following the process is orthogonal to our opinions, positions we took, and our feelings. Now, more than ever, it’s important to be nice to each other, have a lot of compassion and not be condescending, whatever group you belong to. So, I am sending hugs to all my fellow Debian colleagues no matter whether the are pro-systemd, anti-systemd, anything in between, or something completely different. Happy new year to all of you and the Debian project as whole. Ondřej -- Ondřej Surý
Re: Some thoughts about Diversity and the CoC
The problem here is there were several responses telling Gerardo that his email was totally unacceptable in Debian and we don’t share his views, but the format of the media (mailing list) doesn’t allow a simple way to express +1 without generating thousands and thousands of emails. Ondrej -- Ondřej Surý > On 23 Dec 2019, at 22:13, Pierre-Elliott Bécue wrote: > > And having seen almost no one telling Geraldo such a thing, I find it > disturbing to see that much people getting out of the woods to suddenly > say that "oh well, equality is mandatory".
Re: Merry Christmas more debian private leaks
Oh, just fuck off. Merry Christmas to everyone else. -- Ondřej Surý > On 24 Dec 2019, at 12:55, Santa Claus wrote: > > You can't polish a turd > > No matter how hard you try, you can't conduct a bullying experiment on > volunteers for over a year and claim you are making the community better. > > A turd is still a turd and bullying is still bullying, no matter what the > cabal calls it or what stories they make up to justify it. > > Merry Christmas > > Download debian-private today thanks to IPFS > > https://ipfs.io/ipfs/QmNgEAYhpb3djgmZWcdNM2jN3epDmfGym89U41Jt2zr9tL > >
Re: Some thoughts about Diversity and the CoC
I concur with Scott, personally, I find content of Geraldo’s email(s) totally unacceptable at the same time as I find the language of Tina’s email inappropriate. Ondřej -- Ondřej Surý > On 13 Dec 2019, at 15:21, Scott Kitterman wrote: > > > >> On December 13, 2019 11:53:21 AM UTC, Enrico Zini >> wrote: >>> On Fri, Dec 13, 2019 at 10:49:12AM +0100, Bernd Zeimetz wrote: >>> >>> No, either we have a CoC or not. >>> If it goes so much against your believes, humanity or whatever else, >>> that you can't answer in a sane language, ask somebody else to answer >>> in your name. Especially when you are in a team that wants to keep >>> the CoC upright. >> >> If one focuses on Tina instead of looking at Gerardo's history of >> behaviour on Debian list, and is actually in common faith trying to >> make >> sense of an extreme reaction, I suggest these links for a bit of >> context: >> >> * https://en.wikipedia.org/wiki/Sealioning >> * https://en.wikipedia.org/wiki/Tone_policing >> * >> https://blog.valerieaurora.org/2019/01/09/repost-how-calls-for-civility-are-harming-tech-companies/ >> >> TL;DR: there is a widespread form of oppression which consists in >> politely but relentlessly asking minorities to justify themselves. >> >> As long as we allow it to happen in Debian list, as I observe that we >> do, I do expect that somebody loses it at some point. I believe that >> the >> person who engages in sealioning, and those who enable them to continue >> doing so, should at least get to share in the blame. > > I disagree that's what's happening here. > > I expect that virtually no one in Debian finds Gerardo's message acceptable > (speaking for myself, I don't). I think Joerg's reply to it addressed it > directly and completely. I don't think his (Joerg's) point of view is at all > controversial in Debian. No one (except Gerardo) is asking anyone to justify > their existence. > > I even understand getting very upset about a message like that and using > intemperate language. It's not like I haven't done it myself for other > reasons. > > For me, if Martina had expressed some recognition that the choice of language > was not appropriate for a Debian list (remember, I'm specifically not talking > about the content, I've no significant issue with that), then that would have > been the end of it for me. We all make mistakes. > > That's not what happened though. They claimed a special privilege to use > language that would not be acceptable for others to use on Debian lists. I > find that generally troubling, particularly so for someone who has claimed > the role of an interpreter of the CoC. > > Scott K > > P.S. FOAD, when I kvetched about use of language on -vote and inadvertently > set off this thread, things like Gerardo's views on gender were absolutely > not what I was talking about. >
Re: One-Time Pad Encryption Software to Debian Repository
Michael, your understanding is correct and it’s XOR. Also the use of the password is more harmful than useless. If you glance in the source code, the author just generates MD from the password and XOR the input with it as a “protection”. This is more than useless this is actively harmful. There’s more nonsense about combining two random numbers into one for “even more random”. (Oh gee, why we haven’t thought about this before...) Anyway, after some more private conversation with the author, I think he’s beyond help. He’s so convinced that he’s right and standards based crypto has been flawed by NSA that he’s unable to listen. He’s also unable to understand that one must look at the security of the whole system and not just the security properties of the one-time pad function. Not to mention that he consistently calls functions that do XOR “encrypt” in the code. I am sorry to say that it seems the Schneier’s law is in effect here... And I would normally ignore this, but perhaps some poor soul who Googles FinalCrypt will find this email and won’t put their sensitive data into the hands of this... Ondřej -- Ondřej Surý > On 15 Oct 2019, at 22:03, Michael Stone wrote: > > On Tue, Oct 15, 2019 at 05:07:33PM +0200, Ondřej Surý wrote: >> First of all, all software in Debian must adhere to Debian Free Software >> Guidelines. And I can’t find the source code anywhere on your website. >> >> That said - who you seem to use a lot of buzz words and bold claims, but I >> would recommend the old wisdom: “don’t ever roll your own crypto”. I would >> recommend you to speak to an actual cryptographer before you do more harm to >> your users. >> >> I hope a cryptographic software based on hand-waving and no crypto audit >> would >> never be uploaded in Debian. > > Source code seems to be at > http://www.finalcrypt.org/downloads/other/finalcrypt_sourcecode.zip > but otherwise I agree that using this versus a recognized encryption tools is > a bad idea. The general mechanism seems to to generate a random string equal > to the size of the input data, then perform some operation (presumably xor?) > to generate ciphertext. The usual weak link from a theoretical standpoint is > the strength of the pseudo random number generator. In this case it's using > the java SecureRandom function, so it's as strong or weak as that. If you > don't trust complicated mathematical functions to secure your data, I don't > know why you'd trust SHA-256. The weak link from a practical standpoint is > the need to securely store random pads equal in size to the data > encrypted--if you can secure the one time pad, you could just as easily > secure the data and not need the one time pad. Disclaimer: I only gave the > source code a cursory glance so there may be additional elements of this > implementation that I overlooked either for better or for worse.
Re: One-Time Pad Encryption Software to Debian Repository
First of all, all software in Debian must adhere to Debian Free Software Guidelines. And I can’t find the source code anywhere on your website. That said - who you seem to use a lot of buzz words and bold claims, but I would recommend the old wisdom: “don’t ever roll your own crypto”. I would recommend you to speak to an actual cryptographer before you do more harm to your users. I hope a cryptographic software based on hand-waving and no crypto audit would never be uploaded in Debian. Ondřej -- Ondřej Surý > On 15 Oct 2019, at 16:42, FinalCrypt wrote: > > > Hello, > > Regularly I get questions from Debian (based Linux) users, which FinalCrypt > package (*.deb / *.rpm) they should install. > Would you be interested in having the latest FinalCrypt Debian package added > to the Debian Repository ? > > Currently there is no Linux distribution that offers mature One-Time Pad > Encryption software from its repository. > Debian could be the first to offer mature unbreakable encryption software and > of course I would feel honored as well. > > Surprisingly enough currently there is no serious alternative One-Time Pad > File Encryption software besides FinalCrypt. > > Here is a small list of why users would choose FinalCrypt: > > • FinalCrypt uses unbreakable One-Time Pad File Encryption > • Revolutionary Automatic Keys on One-Time Pad Encryption > • Installation & Portable Packages for Windows, Mac & Linux > • Completely Free of Use including Free Support for all Users > • Independently tested for Safety at 70 AnitVirus Companies > • Non-Profit OpenSource private initiative for Digital Privacy > • If you already use encryption it probably is AES encryption > • Asymmetric encryption is vulnerable to The Shor's Algorithm > • Disk Encryption does NOT protect you from active Spyware > • Today's Mass Privacy Violations in the Cyber Security News > • FinalCrypt protects your Constitutional & Human Rights §8 > > FinalCrypt software packages come with a working JRE as the default Linux JRE > do not contain the JavaFX GUI Widget Toolkit. > Besides offering a modern GUI, FinalCrypt also offers a fully featured > Command Line Interface to automate OTP encryption. > > Kind regards, > > Ron de Jong > FinalCrypt
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
> Do you ask me to increase my work load to at least 300% only because of some > standardization procedure for the minuscule chance that I am suddenly > abducted by aliens? No, it’s not about being abducted by the aliens, but there are other more realistic factors that might get any developer to stop contributing. I find it useless to list them all just to prevent you from strawmanning. > (Or, heretic voice, maybe because it is easier to > throw people out when everything is standardized?) Anyway, I am really really tired of your whining in just every message you send, so I am just blacklisting you. Ondrej -- Ondřej Surý ond...@sury.org
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
> so, why isn't it enough to recommend those things? Because you are not the only developer in the whole world? And when you disappear or just don’t have a time and somebody else needs to fix your packages, then it’s a heap of unnecessary trouble to go through because of someones “personal” preferences. Debian is a team effort and it always was, although it sometimes look like a team of zen-buddhists - each walking a different path and different direction - we do converge to a common goal at the end. It’s fine to be a different, but when it hinders other’s ability to contribute sometimes it’s better to bite the bullet and be nice to your fellow Debian Developers by making your packaging accessible. Ondrej -- Ondřej Surý ond...@sury.org
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
> Most other distributions I know about seem to have only the packaging > information (debian/*) and not the upstream source in their version > control system. So more people might be familiar with this; it also > also makes tree-wide changes to packaging much easier ;-) Is there a tooling around gbp that can do that? It would be great if there was. Ondrej -- Ondřej Surý ond...@sury.org
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
> On 23 Jul 2019, at 15:11, Thomas Goirand wrote: > > > The idea is to be able to use unified tooling. Currently, we can't for > example easily do a mass-commit on all packages. Or apply a new CI test > to all packages. And that's even without considering the entry barrier > for contributing to the Debian archive. In for example FreeBSD, it's a > way more obvious how to contribute to /usr/ports. In Debian, it's not. Well, yes, please. We should have done that years ago. It’s extremely bothersome if you need to help fix a other developer/maintainer’s package and they don’t use DVCS (well, I mean git) and a layout that gbp can work with smoothly. I usually end up importing packages into gbp and working from the local mirror. But it is bothersome. Thanks for doing that, -- Ondřej Surý ond...@sury.org
Re: Debian supports pridemonth?
> On 2 Jul 2019, at 14:53, Gerardo Ballabio wrote: > > In fact, I agree that the Publicity Team should normally be trusted to > do the right thing. Can we just settle on this and move on with our lives? Ondrej -- Ondřej Surý ond...@sury.org
Re: Debian supports pridemonth?
On 28 Jun 2019, at 15:55, Sam Hartman wrote: >>>>>> "Roberto" == Roberto C Sánchez writes: > >Roberto> It does not seem that anything was done with the intent to >Roberto> conceal the action, nor do I mean to imply such. However, >Roberto> the start of the thread was practically invisible >Roberto> (especially for someone monitoring many Debian-related >Roberto> mailing lists). I would be surprised if more than a very >Roberto> small handful people even knew such a change was in the >Roberto> works. > > The interesting question is whether those active in the publicity team > were aware of the change. > The whole point of delegation is to allow small groups of people to act > quickly without reaching project consensus for everything. > > If we're hearing from active parts of the www or publicity team that > this was inadequately discussed, that's one thing. > > The publicity team can seek broader project input when they need to, but > has wide latitude within their area of responsibility. And that’s how it should be. Thanks, Sam! Ondřej -- Ondřej Surý
Re: Realizing Good Ideas with Debian Money
Again I would suggest looking at https://tools.ietf.org/html/rfc4071 as a start to learn from the experience of others. It’s a change in paradigm, but somehow I feel that this is needed if we want to keep up to par with other parties in the same field. P.S.: At no point of time I am speaking about packaging work paid by Debian, but there are other functions that would benefit from having staff on full time dedicated to that function and being accountable to the Debian project and not to their employers. Cheers, Ondrej -- Ondřej Surý > On 1 Jun 2019, at 06:12, Russ Allbery wrote: > > Ximin Luo writes: > >> Nobody is suggesting that it won't be a hard problem to get right, but >> progress isn't made by worrying about all the things that could possibly >> go wrong. Figuring out a blueprint for organising large-scale work >> using more directly-democratic principles would have lots of benefits >> far beyond this project. > > Yup, this is fair, and I admit that I tend to see the problems more > readily than the opportunities. > > My core point is that I personally don't believe this is the right > experiment for us. I don't think Debian is the right organization to try > this. I don't think we have the expertise and the muscle in the right > places to be the project to lead in this specific area. > > However, this is just my opinion, and I don't want to try to persaude you > too strongly, because if you're right and I'm wrong and we can make this > work, it would be a very neat positive development. Funding free software > development is an enormous problem right now that desperately needs > options other than controlling sponsorship by for-profit companies with > all the baggage that carries. > >> Then some of the other things you mentioned are not necessarily >> downsides. Making a loaded statement about what work the project >> considers the most important isn't necessarily a bad thing, especially >> if it stands against the loaded statements that Big Tech already puts >> out worldwide, that give engineers (including open source engineers) a >> bad name in front of people that don't know there are less monopolistic >> ways of creating and using technology. > > I think I'm coming from a place where I feel like our community is still > rather fragile, and I'm worried about putting more stress on it by making > those sorts of loaded statements. But yes, it's entirely possible that > I'm being too cautious. > > I will say this: we only have the energy to make a small number of big > bets like this. If we work on funding development, we're *not* going to > work on most, if not all, of the other big bet ideas that the project > could work on. > > Now, that's possibly better than not working on *any* big bets, and we do > have a tendency to default into not changing anything, and that isn't > going to serve us well in the long run. I'm in favor of picking something > big and going for it. But I think we should pick one or two big things, > no more, and try those things until they reach some agreed-upon conclusion > before adding more on. > > -- > Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> >
Re: Realizing Good Ideas with Debian Money
It might be worth looking on how other organizations in our ballpark are doing stuff. f.e. IETF/ISOC is in similar situation to Debian/SPI. I am not directly involved in looking into IETF financials, but they have contracts for certain functions (Ops, RFC Editor to name few, for full list see https://iaoc.ietf.org/contracts.html). I agree that crunching the numbers must be a first step, then next step might be identifying roles within the project that can have clear job descriptions, that might also include roles that we currently don’t have because it can’t be filled by volunteers work. Then this must also include balancing whether we can improve the function if the function is contracted and there are “hard” requirements. Personally, I don’t have any problem with paying people with Debian money if the competition for the function is transparent (thus done by third party in our case), time-limited and clearly specified so we can end the contract if the conditions are not fulfilled by the other party. Ondrej -- Ondřej Surý > On 1 Jun 2019, at 01:07, Russ Allbery wrote: > > Adrian Bunk writes: > >> My biggest high level concern is the income side, since this is the most >> difficult part and will likely also be the most controversial one. > > I could well be entirely wrong, but the part that I would expect to be the > most controversial is that, once Debian starts spending project money to > pay people to do work that other people in the project are doing for free, > the project is doing a form of picking winners and losers. We're deciding > as a project that some people's work is valuable enough to pay for and (by > omission if nothing else) other people's work is not, and for all the good > intentions that we have going in, there are so many ways for this to go > poorly. > > If we're only hiring people from *outside* the project, not each other, > maybe that avoids the worst of the problems, but it's still an odd > dynamic. For example, it creates a perverse incentive for someone to > resign from the project so that they can be paid for the work they're > currently doing as a volunteer. > > I'm particularly concerned what will happen if something goes wrong: we > pay someone to do additional work and that work isn't up to the quality > standards that we need. Now what? If that person is also a Debian > Developer, we have now introduced an aspect of job performance feedback > into a volunteer community. While doubtless there are Debian Developers > who are also managers in their day jobs, that's not something anyone is > currently doing *in Debian*. Managing feedback and consequences for poor > performance is a skill that we are not currently exercising and that is > not trivial to learn. > > These problems generally go away with externally-funded initiatives such > as LTS. In that case, even when Debian Developers are involved, it's > clear that the person with the money is making contract and hiring > decisions, is the person who can decide to fire someone from that contract > if they don't like the work being done, and any decisions made there are > entirely separate from one's ongoing Debian work as a volunteer. People > still have to decide what they're willing to do for free and what they > want to be paid for, but it helps a lot that LTS is scoped to one specific > problem and has resources such that, if everyone else decides they're not > willing to do LTS support for free, the initiative still survives. It > also helps considerably that LTS was something we as a project had decided > not to do with pure volunteer resources, so it's a pure incremental on top > of project work. > > Maybe we can find more things like LTS that are pure incrementals over > what the project is currently doing, but I'm pretty worried about the > social dynamic of paying people to do core project work that others are > currently doing for free. > > I assume the above is the sort of thing that Sam is referring to when he > says that we need to have a higher-level discussion if we're going to > pursue this idea. > > -- > Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> >
Re: Debian, Totalitarianism, Thought Reform, what next?
You are absolutely wrong and I find your email disgusting and disrespectful to all the political prisoners you mention in your email. Please do not write your hurtful emails here anymore. Ondrej -- Ondřej Surý > On 26 Mar 2019, at 07:58, Robin Wheeler wrote: > > The humble & humiliating apology made by Comrade Preining last week > smells like the confessions that political prisoners > make after undergoing thought reform and coercive persuasion > programs. The State 100% right and Comrade Prisoner 100% wrong. > Of course. > > How could Preining refuse after DAM leaks his name to newspapers? > So much pressure. > > Demotion like Chinese internment camps for muslims to get their > thought reform treatment. > > Preinings warning looks like Chinese social credit scheme. Why not ask > Chinese GSoC student to copy social credit scoreboard for Debian. > > The elections look like new-era Hong Kong elections, only candidates > from the Party are permitted. > > Anybody else alert to these things? > > > --- > > Take your mailboxes with you. Free, fast and secure Mail Cloud: > https://www.eclipso.eu - Time to change! > >
Re: Binary compatibility policy for security updates and point releases
Jakob, the backward incompatible ABI changes are generally something we avoid in stable releases. There might be occasional exception to the rule where it cannot be avoided, but it is not something we take lightly. Ondrej -- Ondřej Surý > On 17 Mar 2019, at 08:10, Ximin Luo wrote: > > Jakob Leben: >> Hello, >> >> I have not been able to find clear information about Debian policies for ABI >> compatibility across point releases and security updates. I would assume >> that no ABI changes at all (backwards compatible or not) are allowed in >> point releases and security updates. Still, I have not found a clear and >> unambiguous statement to this effect in Debian documentation. >> >> Could someone please confirm the answer to my question? Would Debian >> developers consider improving documentation on this topic? >> > > In general, if no documented guarantee exists then you should assume there is > no guarantee. > > If you are a developer and you link against a particular version of a library > in Debian 9.1 and its ABI changes in 9.2, it's a simple task to rebuild it, > and in fact that is what all reverse-dependencies of that library in Debian > would themselves have to do. Not a big deal; as a developer you are supposed > to deal with these issues and make it transparent to your end users. > > X > > -- > GPG: ed25519/56034877E1F87C35 > GPG: rsa4096/1318EFAC5FBBDBCE > https://github.com/infinity0/pubkeys.git >
Re: enforcement first, ask questions later?
In the past, I’ve seen some communities to wither because of a toxic person violently pushed their agenda on everybody. This is certainly following the similar pattern. That’s my first and last 2 cents to this discussion. Ondřej -- Ondřej Surý > On 4 Feb 2019, at 07:29, Daniel Pocock wrote: > >> On 04/02/2019 02:16, Steve Langasek wrote: >>> On Sun, Feb 03, 2019 at 08:38:54AM +0100, Daniel Pocock wrote: >>> It is a fact that both Lamb and de Blanc have stated at various times >>> during 2018 that they didn't have time to talk to people. It is also a >>> fact that multiple people have complained that Debian leadership figures >>> are too busy to talk to them. Is it acceptable for them to skip over >>> talking to people and rush to enforcement simply because they are busy? >> Yes, it is. >> >> The first duty of the DPL and any delegates is to the Debian Project as a >> whole, not to any individual developer. If the appropriate delegates have >> determined that an individual developer's behavior is damaging to the >> project, they are absolutely justified in enforcing first. >> >> Restorative justice is a worthwhile goal, but it is a luxury. It is not the >> responsibility of the Debian Project to rehabilitate every contributor who >> it's determined has overstepped boundaries. Even ignoring the effect of bad >> actors, that constitutes an open-ended committment. And even if the >> project's representatives HAVE made a committment to rehabilitation, it is >> STILL acceptable to enforce FIRST if in their sole judgement this is >> necessary in order to limit any ongoing damage. >> >> If you don't understand this, then it is unsurprising to me if enforcement >> escalates. >> > > Is that a threat? > >
Re: Emeritus status, and email forwarding
On Fri, Nov 17, 2017, at 23:01, Tollef Fog Heen wrote: > ]] Ian Jackson > > > I think that, with some safeguards[1], this would be a good thing to > > offer people. If nothing else people have often used @d.o addresses > > in Debian work, where the addresses live on after they move on, and we > > should definitely encourage even an emeritus member to be reachable > > for answering questions or whatever, as their time and interest > > permits. > > I don't think we should do that. Once they've left the project, they > don't and shouldn't have the ability to answer for Debian in any way. +1 to that. Either you are with the project, or you are not. If somebody hasn't been active in years, and intend to possibly return, we can recycle the account name, but he should be probably subject to the regular NM procedure. Cheers, -- Ondřej Surý <ond...@sury.org>
Re: Debian-branded USB-powered fans
If nobody steps up, I can store them at my house. But it would be suboptimal, because I don't often come to conferences where they can be sold. I don't know who's planning to have a FOSDEM booth, but maybe they could be shipped to Brussels in advance to the event. Ondrej On Sat, 21 Oct 2017 at 16:36 martin f krafft <madd...@debian.org> wrote: > Hello, > > We have precisely 198 USB-powered fans left over: > > > http://www.werbeartikel-planimed.de/USB-Ventilator-AERO-FRESH-Werbeartikel-1.html > > These have a tiny Debian logo engraved close to the (soft) blades. > > They're currently in our basement and can't stay there. I'm > therefore asking for someone to take them into custody, e.g. for > sale at conferences etc.. > > If by the end of November, nobody's stepped up, I'll be forced to > throw them out or might put them on Ebay. > > So if you want them, let me know. There are two boxes, one with 69 > and the other with 129. It's probably not worth to send these to > anywhere outside Europe. > > -- > .''`. martin f. krafft <madduck@d.o> @martinkrafft > : :' : proud Debian developer > `. `'` http://people.debian.org/~madduck > `- Debian - when you have better things to do than fixing systems > > "when a woman marries again it is because she detested her first husband. > when a man marries again it is because he adored his first wife. > women try their luck; men risk theirs." > -- oscar wilde > -- Ondřej Surý <ond...@sury.org>
Re: No port 443 (https) available at "security.debian.org"-repository
CAA record is meant to be consumed by CA, not by end-users, thus it doesn't provide much protection. O. -- Ondřej Surý <ond...@sury.org> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware, fast DNS(SEC) resolver Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro pečení chleba všeho druhu On Wed, Jul 26, 2017, at 01:01, James Bromberger wrote: > > > On 26/07/2017 6:20 AM, Adam Borowski wrote: > > https provides no protection against targetted attacks by government > > agents. > > The CA cartel model consists of 400+ CAs, many of them outright controlled > > by governments, most of the rest doing what they're told (no, warrants are > > are a story for nice kids). Clients in general trust _any_ CA, which means > > you're only as secure as the worst CA. Ie, https protects you against Joe > > Script Kiddie but not against a capable opponent. > > > > Except there are new-ish ways to limit the scope from 400+ CAs to just > the one you use. > c.f. > /Certification Authority Authorization/ (/CAA/) /DNS/ Resource > https://tools.ietf.org/html/rfc6844 > > ... if APT wishes to support this. > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature)
Re: shutting down httpredir.debian.org?
Hi, On Mon, Apr 25, 2016, at 14:41, Tollef Fog Heen wrote: > ]] Ondřej Surý > > Hi, > > > since you work at Fastly, could you make the deb.debian.org to have IP > > address? :) Currently it's accessible only via Legacy IP although > > static.debian.org has records, it get's redirected to > > global-nossl.fastly.net that's accessible only via Legacy IP which makes > > me very sad. > > deb.d.o has a lower-priority ipv6 fallback, so you should file a bug on > apt asking it to use the lower-priority alternative that has the > protocol you need, since apparently that doesn't work today. I'll try in unstable first as this was a LXC guest with jessie. > Until that gets fixed, you can use cdn-fastly-v6.deb.d.o for v6 support. > It's not the default since too many users ended up in suboptimal places. > Once that's fixed, I'm going to flip the switch back again. I am fine just with the knowledge that this is being worked on. Cheers, -- Ondřej Surý <ond...@sury.org> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Re: shutting down httpredir.debian.org?
Tollef, since you work at Fastly, could you make the deb.debian.org to have IP address? :) Currently it's accessible only via Legacy IP although static.debian.org has records, it get's redirected to global-nossl.fastly.net that's accessible only via Legacy IP which makes me very sad. Cheers, -- Ondřej Surý <ond...@sury.org> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server On Fri, Apr 15, 2016, at 06:48, Tollef Fog Heen wrote: > > What kind of setup is deb.debian.org? > > It's ftp.debian.org fronted by (currently at least), Fastly. (Not sure > if that answers your question? Happy to elaborate if you explain what > you're after.)
Re: DNS Qname minimisation
On Mon, Mar 28, 2016, at 21:30, Florian Weimer wrote: > * Henrique de Moraes Holschuh: > > > On the CDN side, Akamai were warned that their authoritative servers > > were broken and would interfere with Qname minimization in February > > 2015[1], and it is still not fixed. It is the same bad behavior that > > happened to ECN > > It is similar to ECN indeed. In both cases, people changed the > specification, and complained loudly when their changes are > incompatible with the installation base. Not sure if that's the case. I think that Akamain implementation is just broken and needs to be fixed. We'll push Akamai to fix that now that RFC 7816 is out. I completely don't agree with "NAT for DNS", on the contrary, the QNAME minimization is transparent for end clients and can be deployed gradually as resolvers adds support for that. As for the deep-chains -> some .arpa optimizations probably should land in the code, but I would point out, that you are mostly ignoring the caching behaviour of DNS, that would cause QNAME minimization to burst more queries in the beginning, but after the cache is hot, it won't (shouldn't have) much operational impact. The more harm is usually done by TTL < #smallnumberofseconds. O. -- Ondřej Surý <ond...@sury.org> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Re: Frustrated
On Wed, Feb 3, 2016, at 11:11, Michael Meskes wrote: > On Tue, Feb 02, 2016 at 10:12:59PM +, koanhead wrote: > > The cake reference makes me think of Microsoft's presence at LinuxFest > > Northwest last year in Bellingham, WA. MS had a booth there touting their > > Azure service and giving out blue cake. Possibly they have given away > > cake at other venues as well- I understand they can afford a lot of cake. > > Well, they did give away the cake for one reason, to celebrate Debian's > birthday. No idea why this could be bad though. Well, I got a life-threat email into my INBOX for removing support for sqlite (2.x, the one old obsolete version) from PHP[*]. Not everything on the Internet does have to make sense :). (* - Not to mention that some would argue that packaging PHP is a life-threat on it's own :))). Cheers, -- Ondřej Surý <ond...@sury.org> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Re: What do you expect from the DPL?
Just few random notes... On Fri, Feb 13, 2015, at 04:08, Paul Wise wrote: - Mediation regarding social and technical problems The former seems like the responsibility of Debian as a whole and the latter is the responsibility of the CTTE. I have several occasions in my mind when I would be happy if someone has stepped in and helped with mediation. For my own sake, and for the problem sake. I view CTTE as a heavy hitter and DPL could use more soft approach before the parties approach CTTE. Also sometimes there is a feud between developer and delegate. This is also area where DPL could step in and help with the outcome. I can provide specific examples off-list. - Be aware of everything that goes on with Debian. E.g. I have the feeling some people expect the DPL to read all the Debian mailing lists. That is simply not feasible, even though the amount of discussion that goes on in Debian feels like it is going down over time. Just the sole idea of reading all the mailing lists gives me shivers. O. -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1424115598.3334844.228244697.336a5...@webmail.messagingengine.com
Nominating Committee for tech-ctte
Hey, just an idea worth considering and thinking about for a while. Perhaps we should copy the model from other large organisations - instead of having a direct vote on tech-ctte members we could form a Nominating Committee that would select the members. That would give the tech-ctte a strong mandate that would not be that heavily influenced by populism. Also the NomCom could approach the right candidates instead of waiting for (self-)nominations. I understand that there might not be enough people for two governance bodies, but on the other hand, the NomCom job would not take as much time as tech-ctte and the criteria would also be different. This would also allow us to also experiment with more wild ideas like having a DD-only NomCom, but non-DD tech-ctte member(s) - f.e. an emeritus member. (Not saying this is necessarily good idea, but just that it would be possible.) Cheers, -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1419267106.884823.205779877.6de27...@webmail.messagingengine.com
Re: Bug#772645: lists.debian.org: Please create debian-moderat...@lists.debian.org
Since Raphael asked for support, I am hereby publicly declaring that I support such idea and the list creation. Cheers, Ondrej On Tue, Dec 9, 2014, at 15:31, Raphael Hertzog wrote: Package: lists.debian.org Severity: wishlist Hello, with the adoption of the code of conduct, more and more people started to respond to persons who do not follow its spirit, to let them know that the message was inappropriate in one way or another. Some do it publicly and other do it privately. This is good. Unfortunately, when such a message is sent publicly on the same mailing list, it oftens degenerates in a small sub-thread. This is bad because it generates useless tension and because its brings down the signal/noise ratio on the given list. At the same time, those discussions are also necessary to have some balance and remember collectively that we do not want to over-regulate our mailing lists either. Thus I would like to have a new mailing list called debian-moderat...@lists.debian.org that moderators (i.e. contributors who are telling others that their behaviour was inappropriate, or contributors refuting such claims) would use. The complaint would go the interested person and would be carbon copied to this list. This has multiple benefits: - people acting as moderators get a better feel of what can be done and what can't be done (by following what others are doing they auto-regulate themselves) - listmasters can monitor the list to detect regular offenders and take more informed decisions for (temporary) bans - meta-discussions no longer pollute our work mailing lists To not exclude moderators who are unwilling to send complaints publicly, I believe that the mailing list should be private (but archived with archives accessible to DD only) and only open to Debian developers by default. Possibly non-DD could join but they would need the invitation of a DD. A copy of this mail is sent to debian-project, both to have some public discussion of this idea (in that case, please do not keep the bug in copy), and to sollicit a few ack from other DD who are already doing that kind of moderation work (or would like to start doing it in a more organized way). Thank you. FTR, this idea was initially submitted in a debian-private thread discussing the code of conduct. -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141209143104.ga19...@home.ouaza.com -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1418654474.28991.203059533.28cd8...@webmail.messagingengine.com
Paradigm shift in a Debian project culture
[Ian has asked me to repost to -project, so here it is.] Hey all, just a thought I am having by reading the emails in the Debian Mailing Lists. This represents only my view of the situation and not necessarily any grand truth. It seems to me that we are having a paradigm shift how the internal culture in the Debian project should look like. Several things has happened that might have contributed to this change: a) the project got bigger, b) we got older, c) new generation came, d) [add yours...] I rememeber that a while back we have valued contributing people (almost) only based on the level of their technical expertise, and no matter how difficult they was to work with, we didn't take the social aspect into the merit. Right now I am seeing that a considerable part of the project moved into the direction that they think that the social aspect of the communication is also important for the project and it affects the project as a whole, and the technical expertise should not be the only scale we care about. This might be very scary for everybody since this is something you can't measured[1], but it can be only shown in a conversation with other folks. Also a Debian might be a safe place where you don't have to think about what you say. Or perhaps there's another reason for people around. And also it's a huge paradigm shift, and paradigm shifts are always resisted. Personally I really think that this paradigm shift is what the Debian project need to stay alive. And if the Debian project is doomed to end, it won't be because of some technical decision, but because we are no longer able to work together. I also think we need to take an action and reflect this paradigm change in our basic documents. I do not have a solution right now, but perhaps we can talk to other groups of people who are not constantly entangled into a flamewars how they have solved this problem and learn from them. But I am deeply convinced that we need to reflect the new paradigm and we need to transform Debian project to a place that is safe place[2] just for everyone from bottom to up. Debian is part of our lives and it's quite similar to your home, to your work - you wouldn't want to stay in a place where you don't feel good. 1. Well, you sort of can, but we don't want the people to take personality inventory questionnaire as a part of becoming the DD. 2. The safe place doesn't mean unicorns and rainbows... Cheers, -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417024931.3262059.195755797.32fe5...@webmail.messagingengine.com
