Add missing blogpost to the buglist

And also change the old blog.ethereum.org links to blog.soliditylang.org

docs/bugs.json

@@ -4,6 +4,7 @@
         "name": "ABIDecodeTwoDimensionalArrayMemory",
         "summary": "If used on memory byte arrays, result of the function ``abi.decode`` can depend on the contents of memory outside of the actual byte array that is decoded.",
         "description": "The ABI specification uses pointers to data areas for everything that is dynamically-sized. When decoding data from memory (instead of calldata), the ABI decoder did not properly validate some of these pointers. More specifically, it was possible to use large values for the pointers inside arrays such that computing the offset resulted in an undetected overflow. This could lead to these pointers targeting areas in memory outside of the actual area to be decoded. This way, it was possible for ``abi.decode`` to return different values for the same encoded byte array.",
+        "link": "https://blog.soliditylang.org/2021/04/21/decoding-from-memory-bug/",
         "introduced": "0.4.16",
         "fixed": "0.8.4",
         "conditions": {
@@ -28,6 +29,7 @@
         "name": "EmptyByteArrayCopy",
         "summary": "Copying an empty byte array (or string) from memory or calldata to storage can result in data corruption if the target array's length is increased subsequently without storing new data.",
         "description": "The routine that copies byte arrays from memory or calldata to storage stores unrelated data from after the source array in the storage slot if the source array is empty. If the storage array's length is subsequently increased either by using ``.push()`` or by assigning to its ``.length`` attribute (only before 0.6.0), the newly created byte array elements will not be zero-initialized, but contain the unrelated data. You are not affected if you do not assign to ``.length`` and do not use ``.push()`` on byte arrays, or only use ``.push(<arg>)`` or manually initialize the new elements.",
+        "link": "https://blog.soliditylang.org/2020/10/19/empty-byte-array-copy-bug/",
         "fixed": "0.7.4",
         "severity": "medium"
     },
@@ -36,6 +38,7 @@
         "name": "DynamicArrayCleanup",
         "summary": "When assigning a dynamically-sized array with types of size at most 16 bytes in storage causing the assigned array to shrink, some parts of deleted slots were not zeroed out.",
         "description": "Consider a dynamically-sized array in storage whose base-type is small enough such that multiple values can be packed into a single slot, such as `uint128[]`. Let us define its length to be `l`. When this array gets assigned from another array with a smaller length, say `m`, the slots between elements `m` and `l` have to be cleaned by zeroing them out. However, this cleaning was not performed properly. Specifically, after the slot corresponding to `m`, only the first packed value was cleaned up. If this array gets resized to a length larger than `m`, the indices corresponding to the unclean parts of the slot contained the original value, instead of 0. The resizing here is performed by assigning to the array `length`, by a `push()` or via inline assembly. You are not affected if you are only using `.push(<arg>)` or if you assign a value (even zero) to the new elements after increasing the length of the array.",
+        "link": "https://blog.soliditylang.org/2020/10/07/solidity-dynamic-array-cleanup-bug/",
         "fixed": "0.7.3",
         "severity": "medium"
     },
@@ -104,7 +107,7 @@
         "name": "MemoryArrayCreationOverflow",
         "summary": "The creation of very large memory arrays can result in overlapping memory regions and thus memory corruption.",
         "description": "No runtime overflow checks were performed for the length of memory arrays during creation. In cases for which the memory size of an array in bytes, i.e. the array length times 32, is larger than 2^256-1, the memory allocation will overflow, potentially resulting in overlapping memory areas. The length of the array is still stored correctly, so copying or iterating over such an array will result in out-of-gas.",
-        "link": "https://solidity.ethereum.org/2020/04/06/memory-creation-overflow-bug/",
+        "link": "https://blog.soliditylang.org/2020/04/06/memory-creation-overflow-bug/",
         "introduced": "0.2.0",
         "fixed": "0.6.5",
         "severity": "low"
@@ -173,7 +176,7 @@
         "name": "SignedArrayStorageCopy",
         "summary": "Assigning an array of signed integers to a storage array of different type can lead to data corruption in that array.",
         "description": "In two's complement, negative integers have their higher order bits set. In order to fit into a shared storage slot, these have to be set to zero. When a conversion is done at the same time, the bits to set to zero were incorrectly determined from the source and not the target type. This means that such copy operations can lead to incorrect values being stored.",
-        "link": "https://blog.ethereum.org/2019/06/25/solidity-storage-array-bugs/",
+        "link": "https://blog.soliditylang.org/2019/06/25/solidity-storage-array-bugs/",
         "introduced": "0.4.7",
         "fixed": "0.5.10",
         "severity": "low/medium"
@@ -183,7 +186,7 @@
         "name": "ABIEncoderV2StorageArrayWithMultiSlotElement",
         "summary": "Storage arrays containing structs or other statically-sized arrays are not read properly when directly encoded in external function calls or in abi.encode*.",
         "description": "When storage arrays whose elements occupy more than a single storage slot are directly encoded in external function calls or using abi.encode*, their elements are read in an overlapping manner, i.e. the element pointer is not properly advanced between reads. This is not a problem when the storage data is first copied to a memory variable or if the storage array only contains value types or dynamically-sized arrays.",
-        "link": "https://blog.ethereum.org/2019/06/25/solidity-storage-array-bugs/",
+        "link": "https://blog.soliditylang.org/2019/06/25/solidity-storage-array-bugs/",
         "introduced": "0.4.16",
         "fixed": "0.5.10",
         "severity": "low",
@@ -244,7 +247,7 @@
         "name": "ABIEncoderV2PackedStorage",
         "summary": "Storage structs and arrays with types shorter than 32 bytes can cause data corruption if encoded directly from storage using the experimental ABIEncoderV2.",
         "description": "Elements of structs and arrays that are shorter than 32 bytes are not properly decoded from storage when encoded directly (i.e. not via a memory type) using ABIEncoderV2. This can cause corruption in the values themselves but can also overwrite other parts of the encoded data.",
-        "link": "https://blog.ethereum.org/2019/03/26/solidity-optimizer-and-abiencoderv2-bug/",
+        "link": "https://blog.soliditylang.org/2019/03/26/solidity-optimizer-and-abiencoderv2-bug/",
         "introduced": "0.5.0",
         "fixed": "0.5.7",
         "severity": "low",
@@ -257,7 +260,7 @@
         "name": "ABIEncoderV2PackedStorage_0.4.x",
         "summary": "Storage structs and arrays with types shorter than 32 bytes can cause data corruption if encoded directly from storage using the experimental ABIEncoderV2.",
         "description": "Elements of structs and arrays that are shorter than 32 bytes are not properly decoded from storage when encoded directly (i.e. not via a memory type) using ABIEncoderV2. This can cause corruption in the values themselves but can also overwrite other parts of the encoded data.",
-        "link": "https://blog.ethereum.org/2019/03/26/solidity-optimizer-and-abiencoderv2-bug/",
+        "link": "https://blog.soliditylang.org/2019/03/26/solidity-optimizer-and-abiencoderv2-bug/",
         "introduced": "0.4.19",
         "fixed": "0.4.26",
         "severity": "low",
@@ -270,7 +273,7 @@
         "name": "IncorrectByteInstructionOptimization",
         "summary": "The optimizer incorrectly handles byte opcodes whose second argument is 31 or a constant expression that evaluates to 31. This can result in unexpected values.",
         "description": "The optimizer incorrectly handles byte opcodes that use the constant 31 as second argument. This can happen when performing index access on bytesNN types with a compile-time constant value (not index) of 31 or when using the byte opcode in inline assembly.",
-        "link": "https://blog.ethereum.org/2019/03/26/solidity-optimizer-and-abiencoderv2-bug/",
+        "link": "https://blog.soliditylang.org/2019/03/26/solidity-optimizer-and-abiencoderv2-bug/",
         "introduced": "0.5.5",
         "fixed": "0.5.7",
         "severity": "very low",
@@ -283,7 +286,7 @@
         "name": "DoubleShiftSizeOverflow",
         "summary": "Double bitwise shifts by large constants whose sum overflows 256 bits can result in unexpected values.",
         "description": "Nested logical shift operations whose total shift size is 2**256 or more are incorrectly optimized. This only applies to shifts by numbers of bits that are compile-time constant expressions.",
-        "link": "https://blog.ethereum.org/2019/03/26/solidity-optimizer-and-abiencoderv2-bug/",
+        "link": "https://blog.soliditylang.org/2019/03/26/solidity-optimizer-and-abiencoderv2-bug/",
         "introduced": "0.5.5",
         "fixed": "0.5.6",
         "severity": "low",
@@ -297,7 +300,7 @@
         "name": "ExpExponentCleanup",
         "summary": "Using the ** operator with an exponent of type shorter than 256 bits can result in unexpected values.",
         "description": "Higher order bits in the exponent are not properly cleaned before the EXP opcode is applied if the type of the exponent expression is smaller than 256 bits and not smaller than the type of the base. In that case, the result might be larger than expected if the exponent is assumed to lie within the value range of the type. Literal numbers as exponents are unaffected as are exponents or bases of type uint256.",
-        "link": "https://blog.ethereum.org/2018/09/13/solidity-bugfix-release/",
+        "link": "https://blog.soliditylang.org/2018/09/13/solidity-bugfix-release/",
         "fixed": "0.4.25",
         "severity": "medium/high",
         "check": {"regex-source": "[^/]\\*\\* *[^/0-9 ]"}
@@ -307,7 +310,7 @@
         "name": "EventStructWrongData",
         "summary": "Using structs in events logged wrong data.",
         "description": "If a struct is used in an event, the address of the struct is logged instead of the actual data.",
-        "link": "https://blog.ethereum.org/2018/09/13/solidity-bugfix-release/",
+        "link": "https://blog.soliditylang.org/2018/09/13/solidity-bugfix-release/",
         "introduced": "0.4.17",
         "fixed": "0.4.25",
         "severity": "very low",
@@ -318,7 +321,7 @@
         "name": "NestedArrayFunctionCallDecoder",
         "summary": "Calling functions that return multi-dimensional fixed-size arrays can result in memory corruption.",
         "description": "If Solidity code calls a function that returns a multi-dimensional fixed-size array, array elements are incorrectly interpreted as memory pointers and thus can cause memory corruption if the return values are accessed. Calling functions with multi-dimensional fixed-size arrays is unaffected as is returning fixed-size arrays from function calls. The regular expression only checks if such functions are present, not if they are called, which is required for the contract to be affected.",
-        "link": "https://blog.ethereum.org/2018/09/13/solidity-bugfix-release/",
+        "link": "https://blog.soliditylang.org/2018/09/13/solidity-bugfix-release/",
         "introduced": "0.1.4",
         "fixed": "0.4.22",
         "severity": "medium",
@@ -371,7 +374,7 @@
         "name": "ConstantOptimizerSubtraction",
         "summary": "In some situations, the optimizer replaces certain numbers in the code with routines that compute different numbers.",
         "description": "The optimizer tries to represent any number in the bytecode by routines that compute them with less gas. For some special numbers, an incorrect routine is generated. This could allow an attacker to e.g. trick victims about a specific amount of ether, or function calls to call different functions (or none at all).",
-        "link": "https://blog.ethereum.org/2017/05/03/solidity-optimizer-bug/",
+        "link": "https://blog.soliditylang.org/2017/05/03/solidity-optimizer-bug/",
         "fixed": "0.4.11",
         "severity": "low",
         "conditions": {
@@ -403,7 +406,7 @@
         "name": "HighOrderByteCleanStorage",
         "summary": "For short types, the high order bytes were not cleaned properly and could overwrite existing data.",
         "description": "Types shorter than 32 bytes are packed together into the same 32 byte storage slot, but storage writes always write 32 bytes. For some types, the higher order bytes were not cleaned properly, which made it sometimes possible to overwrite a variable in storage when writing to another one.",
-        "link": "https://blog.ethereum.org/2016/11/01/security-alert-solidity-variables-can-overwritten-storage/",
+        "link": "https://blog.soliditylang.org/2016/11/01/security-alert-solidity-variables-can-overwritten-storage/",
         "severity": "high",
         "introduced": "0.1.6",
         "fixed": "0.4.4"