Daniel Stadulis [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-06-04 to 2017-09-11
💬 Posted a total of 8 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:05:52

- reply

📅 Original date posted:2017-09-11
📝 Original message:I think it's relevant to treat different bug severity levels with different
response plans.
E.g.
Compromising UTXO custody (In CVE-2010-5141, OP_RETURN vulnerability)
Compromising UTXO state (In CVE-2013-3220, blockchain split due to Berkeley
DB -> LevelDB upgrade, CVE-2010-5139 Overflow bug, unscheduled inflation of
coins)
Compromising Node performance (Various node-specific DoS attacks)
Should have different disclosure policies, IMO
On Mon, Sep 11, 2017 at 4:34 AM, Alex Morcos via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I don't think I know the right answer here, but I will point out two
> things that make this a little more complicated.
>
> 1 - There are lots of altcoin developers and while I'm sure the majority
> would greatly appreciate the disclosure and would behave responsibly with
> the information, I don't know where you draw the line on who you tell and
> who you don't.
>
> 2- Unlike other software, I'm not sure good security for bitcoin is
> defined by constant upgrading. Obviously upgrading has an important
> benefit, but one of the security considerations for Bitcoin is knowing that
> your definition of the money hasn't changed. Much harder to know that if
> you change software.
>
>
>
> On Sun, Sep 10, 2017 at 10:15 PM, Anthony Towns via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Sun, Sep 10, 2017 at 07:02:36PM -0400, Matt Corallo via bitcoin-dev
>> wrote:
>> > I believe there continues to be concern over a number of altcoins which
>> > are running old, unpatched forks of Bitcoin Core, making it rather
>> > difficult to disclose issues without putting people at risk (see, eg,
>> > some of the dos issues which are preventing release of the alert key).
>> > I'd encourage the list to have a discussion about what reasonable
>> > approaches could be taken there.
>>
>> That seems like it just says bitcoin core has two classes of users:
>> people who use it directly following mainnet or testnet, and people who
>> make derived works based on it to run altcoins.
>>
>> Having a "responsible disclosure" timeline something like:
>>
>> * day -N: vulnerability reported privately
>> * day -N+1: details shared amongst private trusted bitcoin core group
>> * day 0: patch/workaround/mitigation determined, CVE reserved
>> * day 1: basic information shared with small group of trusted users
>> (eg, altcoin maintainers, exchanges, maybe wallet devs)
>> * day ~7: patches can be included in git repo
>> (without references to vulnerability)
>> * day 90: release candidate with fix available
>> * day 120: official release including fix
>> * day 134: CVE published with details and acknowledgements
>>
>> could make sense. 90 days / 3 months is hopefully a fair strict upper
>> bound for how long it should take to get a fix into a rc; but that's still
>> a lot longer than many responsible disclosure timeframes, like CERT's at
>> 45 days, but also shorter than some bitcoin core minor update cycles...
>> Obviously, those timelines could be varied down if something is more
>> urgent (or just easy).
>>
>> As it is, not publishing vulnerability info just seems like it gives
>> everyone a false sense of security, and encourages ignoring good security
>> practices, either not upgrading bitcoind nodes, or not ensuring altcoin
>> implementations keep up to date...
>>
>> I suppose both "trusted bitcoin core group" and "small group of trusted
>> users" isn't 100% cypherpunk, but it sure seems better than not both not
>> disclosing vulnerability details, and not disclosing vulnerabilities
>> at all... (And maybe it could be made more cypherpunk by, say, having
>> the disclosures to trusted groups have the description/patches get
>> automatically fuzzed to perhaps allow identification of leakers?)
>>
>> Cheers,
>> aj
>>
>> > On 09/10/17 18:03, Simon Liu via bitcoin-dev wrote:
>> > > Hi,
>> > >
>> > > Given today's presentation by Chris Jeffrey at the Breaking Bitcoin
>> > > conference, and the subsequent discussion around responsible
>> disclosure
>> > > and industry practice, perhaps now would be a good time to discuss
>> > > "Bitcoin and CVEs" which has gone unanswered for 6 months.
>> > >
>> > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
>> -March/013751.html
>> > >
>> > > To quote:
>> > >
>> > > "Are there are any vulnerabilities in Bitcoin which have been fixed
>> but
>> > > not yet publicly disclosed? Is the following list of Bitcoin CVEs
>> > > up-to-date?
>> > >
>> > > https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
>> > >
>> > > There have been no new CVEs posted for almost three years, except for
>> > > CVE-2015-3641, but there appears to be no information publicly
>> available
>> > > for that issue:
>> > >
>> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3641
>> > >
>> > > It would be of great benefit to end users if the community of clients
>> > > and altcoins derived from Bitcoin Core could be patched for any known
>> > > vulnerabilities.
>> > >
>> > > Does anyone keep track of security related bugs and patches, where the
>> > > defect severity is similar to those found on the CVE list above? If
>> > > yes, can that list be shared with other developers?"
>> > >
>> > > Best Regards,
>> > > Simon
>> > > _______________________________________________
>> > > bitcoin-dev mailing list
>> > > bitcoin-dev at lists.linuxfoundation.org
>> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> > >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170911/06bf75a1/attachment.html>

2023-06-07 17:41:19

- reply

📅 Original date posted:2015-09-24
📝 Original message:If you weren't able to attend the first, weekly development meeting, the
following are the minutes:
Meeting Title:
#bitcoin-dev Weekly Development Meeting
Meeting Date:
2015-09-24
Meeting Time:
19:00-20:00 UTC
Participants in Attendance:
luke-jr
CodeShark
sipa
morcos
sdaftuar
dstadulis
jtimon
wumpus
jgarzik
kanzure
gmaxwell
cfields
gavinandresen
IRC Chat Logs:
http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/09/24#l1443121200.0
------------------------------
Topics Discussed:
1.
libconsensus and refactoring
2.
All goals for 0.12 release
1.
libsecp256k1 is ready for 0.12?
1.
libsecp256k1 needs a native OSX travis build
1.
cfields has work that moves to the new Travis infrastructure
2.
PROPOSAL: propose libsecp256k1 validation PR as soon as all
currently-in-pipeline API changes are merged
2.
OP_CHECKSEQUENCEVERIFY
3.
mempool limiting
4.
version bits
3.
BIP process
4.
Split off script base classes/execution for use in consensus?
5.
Current/near-term “what are you working on”
1.
versionbits: Codeshark has been working on an implementation
2.
gavinandresen: simple benchmarking framework then plan on optimizing
new block relay/broadcast.
------------------------------
Meeting Conclusions:
Mempool limiting discussion will be delayed until 2015-10-1 meeting
#
Action items
Responsible Parties
ETA
1
Please review 6557 (starting Saturday), 6673 and any other mempool pulls
for concept
Everyone
Next Thurs. meeting (2015-10-01)
2
libsecp256k1 needs a native OSX travis build
3
Propose libsecp256k1 validation PR as soon as all currently-in-pipeline API
changes are merged
4
Review BIP 68, review #6312, #6564
5
versionbits BIP number assignment
gmaxwell
2015-09-25
Google Doc:
https://docs.google.com/document/d/1zsWVaf5H9ECrN1zPutMdD_2ky3fnhQUM411NDrRrc-M/edit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150924/2554b5f9/attachment-0001.html>