sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] Withdrawal of Service - keys.flanga.io


From: DevPGSV Pablo
Subject: Re: [Sks-devel] Withdrawal of Service - keys.flanga.io
Date: Fri, 16 Nov 2018 07:41:53 +0100

I'm not an active member of this community.

I represent a group of people. We recently set up a SKS Keyserver as a way to contribute to the community.
We have had a lot of problems, but we don't have the knowledge and the experience to contribute to the code or to submit pull requests.

I like the SKS Keyserver. I'm glad it exists and I plan on continue using it.

However I'm also glad the is someone with knownledge thinking about starting from scratch taking into account the concerns of the community in order to offer a modern keyserver.

Ryan, I'd like to offer my help in the development of the solution you are drafting up.

- Pablo Salmones




El vie., 16 nov. 2018 a las 3:47, Ryan Hunt (<address@hidden>) escribió:
I’ve been contributing to those discussions and helping come up with those solutions your referencing, not beating on drums.. everyone here knows what the issues are and everyone has been honest about em, this entire mailer’s history is free to review and nobody has been hiding anything.. I just passed a decade subscribed to this mailing list.. Despite all the discussions that have taken place, you keep ringing the bell over and over with your cute little blog.

Right now I’m drafting up a replacement solution and might POC some code for a future proposal if I manage to find the time.. because I’ve got experience and solutions, just not a lot of free time to implement a project this complex.. so if everyone here is going to depend on me for development, well its not going to get very far.. but mebe I can get something off the ground in a modular framework that more people can work with than the existing codebase.

Your other projects do not address the role of the SKS network, there is a need for a distributed list of keys.. for example a friend I grew up with now maintains architectural software builds for a popular Linux distribution, he needs to validate signatures of keys completely automated and in high volume coming from disperse projects and upstream sources.. We run a key server just for this task so he’s not hammering and abusing other key keyservers.. he needs to federate with a decentralized dataset or all that automation starts breaking… He also dont have any need to concern him self with GDPR or nonsensical keys or copyrighted material since its only his build environments that is accessing them. 

-Ryan

On Nov 15, 2018, at 7:07 PM, stuff <address@hidden> wrote:

I think at least a warning should be given to the admins so they understand the full legal risks of running a keyserver.

as far as solutions once again ive actually pointed out that people in the comminity have already come up with solutions so i dont see the need to iterate over the same ideas, i actually link to one post in one of my articles about solutions on here. ive also reeferenced other projects. so i have contributed some solutions and pointed out better ones by others.

i also dont think its needed to be insulting in a debate, its not constructive.

What have you done to try and change things Ryan?

On Thu, 15 Nov 2018 18:53:30 -0700
Ryan Hunt <address@hidden> wrote:



On Nov 15, 2018, at 6:25 PM, Mike <address@hidden> wrote:

So you are angry that i and a few others have reported several bugs, to a system that we would like to see continue to exist?

If there is no dev team, then maybe its time to call it a day instead of pretending everything is ok?


You’d make an excellent politician with this superb ability to speak out both ends, all while being incapable even coming up with solutions, let alone implementing them.

No one here has been pretending its okay, were just not willing to pack it up and call it a day because of you say we should.. there’s literally no chance someone’s going to read your articles and decide to volunteer the time and energy to implementing a solution.. so really everything you’ve done and all your doing is to the detriment of the key server network.. and yet your surprised at the hostility you’ve found here? 

-Ryan

On Thu, 15 Nov 2018 18:12:14 -0700
Ryan Hunt <address@hidden <mailto:address@hidden>> wrote:

Wait, you have the skillset to code attacks and spew articles yet, no capability for solutions? Smells like ignorance is your forte.

You seem to be under the impression that SKS has active developers working on it, the reason the “dev team” is quiet as per your “articles” is there is no friggin dev team, just some maintainers pushing merge requests from people hacking it a bit here and there to fix major problems that can be fixed and keep it compiling on modern systems.

There is nobody actively interested in the development required to re-archectect the SKS backend and infrastructure that had been running fine for a few decades now.. until you came along and made a big stink.. If you have a proposal for a new way of doing things, we’re all dying to hear it.

-Ryan


On Nov 15, 2018, at 6:01 PM, Mike <address@hidden> wrote:

If i had the skill set needed to submit patches i would, but i don't.
But i do have a voice and that can be used to spur on change.

I wrote the articles because there is a clear ignorance here that your displaying really well, which is preventing things from getting fixed. Your clearly angry and not interested in resolving this issue through discussion. That ignorance is going to harm admins as Moritz Wirth and Fabian points out.

Can you say there's no risk to admins financially and legally, because of the poor design of the servers or do they work just fine and they have nothing to worry about?

If performing as designed means: 
failing to deal with oversized keys and chewing up bandwidth and CPU cycles and causing servers to stop responding or the web interface to freeze or spit out garbage is a feature then ok.
or network instability then ok.

Mike :)

and if calling people children and being generally insulting is your thing your not really being constructive with this!


On Fri, 16 Nov 2018 08:45:06 +0800
Matthew Walster <address@hidden <mailto:address@hidden> <mailto:address@hidden <mailto:address@hidden>>> wrote:

On Fri, 16 Nov 2018, 08:36 Mike <address@hidden <mailto:address@hidden> wrote:

Your welcome to blame others for the servers issues.

I and others have pointed out many times over the issues and no one has
fixed them.
Rather than blame me, take responsibility for the servers failings, for
the developers failings.


You are more than welcome to submit patches (or even ideas for patches) if
you want to help improve things. Screaming blue murder helps no-one.

Decent and good developers take bugs and fix them and ensure the ongoing
survival of their software, not blame them on the people who found them and
exposed them!


The software is not broken. It is performing as designed. The same
side-effects are present in Bitcoin but I don't see you making deranged
comments about that...

Your basicly saying we should be able to have weak software and bad people
shouldnt do bad things, thats not how the world works. Take some
responsibility!!!


That's not what anyone is saying. What are you, 12 years old?

And im not a journalist!


You wrote an article.

M




-- 
me <address@hidden <mailto:address@hidden> <mailto:address@hidden <mailto:address@hidden>>>

_______________________________________________
Sks-devel mailing list
address@hidden <mailto:address@hidden> <mailto:address@hidden <mailto:address@hidden>>
https://lists.nongnu.org/mailman/listinfo/sks-devel <https://lists.nongnu.org/mailman/listinfo/sks-devel> <https://lists.nongnu.org/mailman/listinfo/sks-devel<https://lists.nongnu.org/mailman/listinfo/sks-devel>>


-- 
me <address@hidden <mailto:address@hidden>>



-- 
stuff <address@hidden>

_______________________________________________
Sks-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/sks-devel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]