Date   

Re: Purge Private Data - by individual transaction - on trigger

David Enyeart
 

The only mention of the "private data store" aka "private writeset storage" is this sentence:

"Upon validation/commit, the private data is moved to their copy of the private state database and private writeset storage. The private data is then deleted from the transient data store."

Basically, it is a data structure of private data organized by block (similar to the public write sets in the blockchain), that is used to feed other peers that are members of the collection when they are catching up the block height. It is not documented further since it is an implementation detail abstracted from user, but will become more important to document once the purge feature gets implemented.


Dave Enyeart

"Simeon MacMillen" ---05/05/2021 10:50:22 AM---Hi David, In your original email, you mentioned a private data store in addition

From: "Simeon MacMillen" <industrial_eng@...>
To: David Enyeart <enyeart@...>
Cc: fabric <fabric@...>
Date: 05/05/2021 10:50 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Purge Private Data - by individual transaction - on trigger
Sent by: fabric@...





Hi David,

In your original email, you mentioned a private data store in addition
to the transient and private [world] state.  Is the "private data store"
a separate, append-only ledger used with collections?

If there is any documentation on this, I would be interested to learn
more.  (I tried searching through the documentation but haven't located
any references to this term.  The Private Data page only mentions the
state database and transient store.)


Regards,
Simeon MacMillen

Ref:
https://hyperledger-fabric.readthedocs.io/en/release-2.3/private-data/private-data.html 
Ref:
https://hyperledger-fabric.readthedocs.io/en/release-2.3/private-data-arch.html 



On 5/4/21 7:12 AM, David Enyeart wrote:

        Note that deletePrivateData only deletes from private state.
The private data remains in the private data store (committed data) and
transient store (uncommitted data) for other peers that may be running
behind to pull.










Re: Update expired orderer org admin certificate and orderer certs #fabric-questions #fabric-orderer #signcerts #fabric

Chris Gabriel
 

Yes, that is it.  You got it!

On May 5, 2021, at 10:50 AM, Mattia Bolzonella <mattia.bolzonella@...> wrote:

Just to be clear about what you told me to replace in my system channel configuration, sorry but I want to be 100% sure about what I'm doing:
My json looks like this:

"channel_group": {
    "groups": {
      "Application": { <- MAIN SECTION APPLICATION
        "groups": {
          "OrderersMSP": {
            "groups": {},
            "mod_policy""Admins",
            "policies": {
              "Admins": {
                "mod_policy""Admins",
               // other sections
              "Readers": {
              },
              "Writers": {
            },
            "values": { 
              "MSP": {
                "mod_policy""Admins",
                "value": {
                  "config": {
                    "admins": [ 
                      "EXPIRED CERT BASE64" <--- TO REPLACERIGHT?
                     ],
                    "crypto_config": {
                      "identity_identifier_hash_function""SHA256",
                      "signature_hash_family""SHA2"
                    },
                    "fabric_node_ous": {
                      "admin_ou_identifier": {
                        "certificate""NOT EXPIRED",
                        "organizational_unit_identifier""admin"
                      },
                      "client_ou_identifier": {
                        "certificate""SAME as admin_ou_identifier",
                        "organizational_unit_identifier""client"
                      },
                      "enable"true,
                      "orderer_ou_identifier": {
                        "certificate""SAME as previous",
                        "organizational_unit_identifier""orderer"
                      },
                      "peer_ou_identifier": {
                        "certificate""same as previuos",
                        "organizational_unit_identifier""peer"
                      }
                    },
                    .... other sections
                 } 
                }
            }
        }
    }, // End of Application section
    "Consortiums": { <- MAIN SECTION CONSORTIUM
        "groups": {
          "SampleConsortium": {
            "groups": {
              "IfinPeerMSP": {
                "groups": {},
                "mod_policy""Admins",
                "policies": {
                }, // other sections
                "values": {
                  "MSP": {
                    "mod_policy""Admins",
                    "value": {
                      "config": {
                        "admins": [
                          "EXPIRED" <- TO REPLACE?
                        ],
                        "crypto_config": {
                          "identity_identifier_hash_function""SHA256",
                          "signature_hash_family""SHA2"
                        },
                        "fabric_node_ous": {
                          "admin_ou_identifier": {
                            "certificate""NOT Expired",
                            "organizational_unit_identifier""admin"
                          },
                          "client_ou_identifier"
                            "certificate": "NOT Expired",
                            "organizational_unit_identifier""client"
                          },
                          "enable"true,
                          "orderer_ou_identifier": {
                            "certificate""NOT Expired",
                            "organizational_unit_identifier""orderer"
                          },
                          "peer_ou_identifier": {
                            "certificate""NOT Expired",
                            "organizational_unit_identifier""peer"
                          }
                        },
                       // others
                      },
                      "type"0
                    },
                  }
                },
               
              }
            },
        },
      
      },
    // ORDERER SECTION WILL BE MODIFIED IN ANOTHER TRANSACTION


Thank you again,

Mattia
 


Re: Update expired orderer org admin certificate and orderer certs #fabric-questions #fabric-orderer #signcerts #fabric

Mattia Bolzonella
 

Just to be clear about what you told me to replace in my system channel configuration, sorry but I want to be 100% sure about what I'm doing:
My json looks like this:

"channel_group": {
    "groups": {
      "Application": { <- MAIN SECTION APPLICATION
        "groups": {
          "OrderersMSP": {
            "groups": {},
            "mod_policy""Admins",
            "policies": {
              "Admins": {
                "mod_policy""Admins",
               // other sections
              "Readers": {
              },
              "Writers": {
            },
            "values": { 
              "MSP": {
                "mod_policy""Admins",
                "value": {
                  "config": {
                    "admins": [ 
                      "EXPIRED CERT BASE64" <--- TO REPLACERIGHT?
                     ],
                    "crypto_config": {
                      "identity_identifier_hash_function""SHA256",
                      "signature_hash_family""SHA2"
                    },
                    "fabric_node_ous": {
                      "admin_ou_identifier": {
                        "certificate""NOT EXPIRED",
                        "organizational_unit_identifier""admin"
                      },
                      "client_ou_identifier": {
                        "certificate""SAME as admin_ou_identifier",
                        "organizational_unit_identifier""client"
                      },
                      "enable"true,
                      "orderer_ou_identifier": {
                        "certificate""SAME as previous",
                        "organizational_unit_identifier""orderer"
                      },
                      "peer_ou_identifier": {
                        "certificate""same as previuos",
                        "organizational_unit_identifier""peer"
                      }
                    },
                    .... other sections
                 } 
                }
            }
        }
    }, // End of Application section
    "Consortiums": { <- MAIN SECTION CONSORTIUM
        "groups": {
          "SampleConsortium": {
            "groups": {
              "IfinPeerMSP": {
                "groups": {},
                "mod_policy""Admins",
                "policies": {
                }, // other sections
                "values": {
                  "MSP": {
                    "mod_policy""Admins",
                    "value": {
                      "config": {
                        "admins": [
                          "EXPIRED" <- TO REPLACE?
                        ],
                        "crypto_config": {
                          "identity_identifier_hash_function""SHA256",
                          "signature_hash_family""SHA2"
                        },
                        "fabric_node_ous": {
                          "admin_ou_identifier": {
                            "certificate""NOT Expired",
                            "organizational_unit_identifier""admin"
                          },
                          "client_ou_identifier"
                            "certificate": "NOT Expired",
                            "organizational_unit_identifier""client"
                          },
                          "enable"true,
                          "orderer_ou_identifier": {
                            "certificate""NOT Expired",
                            "organizational_unit_identifier""orderer"
                          },
                          "peer_ou_identifier": {
                            "certificate""NOT Expired",
                            "organizational_unit_identifier""peer"
                          }
                        },
                       // others
                      },
                      "type"0
                    },
                  }
                },
               
              }
            },
        },
      
      },
    // ORDERER SECTION WILL BE MODIFIED IN ANOTHER TRANSACTION


Thank you again,

Mattia
 


Re: Update expired orderer org admin certificate and orderer certs #fabric-questions #fabric-orderer #signcerts #fabric

Chris Gabriel
 

Hi Mattia,

Yes, you need to export the environment variables to act as orderer MSP admin, then as Org MSP admin when doing that step.  I would update Orderer Org first, then Org in separate updates but I welcome anyone else’s perspective.  When looking through the config, note the policy as that is the clue to which/how many signatures you need to get to sign the config update transaction.  

Chris

On May 5, 2021, at 10:27 AM, Mattia Bolzonella <mattia.bolzonella@...> wrote:

Hi Chris,
Thank you again for the reply, I'm going to try what you suggested, for the replacement of the admin certs in the various sections of the config, I do that in one whole update, right?

After doing that (the update configuration for the admin cert), I need to replace the `CORE_PEER_MSPCONFIGPATH` variable of the cli in order to proceed with the cosenters config, am I right?

Now I'm facing a minor problem with my TLS CA, since the tlsca-admin cert is also expired, I will disable temporally the TLS on the CA in order to generate new TLS materials for the cosenters (but on this i dunno how to renew the certs of the tlsca admin, if you have any suggestions these are more than welcome)

I'm going to perform these operation tomorrow, I'll keep you posted, thank you again

Mattia



Re: Update expired orderer org admin certificate and orderer certs #fabric-questions #fabric-orderer #signcerts #fabric

Mattia Bolzonella
 

Hi Chris,
Thank you again for the reply, I'm going to try what you suggested, for the replacement of the admin certs in the various sections of the config, I do that in one whole update, right?

After doing that (the update configuration for the admin cert), I need to replace the `CORE_PEER_MSPCONFIGPATH` variable of the cli in order to proceed with the cosenters config, am I right?

Now I'm facing a minor problem with my TLS CA, since the tlsca-admin cert is also expired, I will disable temporally the TLS on the CA in order to generate new TLS materials for the cosenters (but on this i dunno how to renew the certs of the tlsca admin, if you have any suggestions these are more than welcome)

I'm going to perform these operation tomorrow, I'll keep you posted, thank you again

Mattia


Re: Update expired orderer org admin certificate and orderer certs #fabric-questions #fabric-orderer #signcerts #fabric

Chris Gabriel
 

Hi Mattia,

***IMPORTANT**
If you are in production and will have adverse customer impact, I recommend taking a look at doing this until you get it fixed (this is for extreme measures, perform this step at your own risk):
Just remember to undo this after updating your certs!!
*********************

You are on the right track!  Take a look below:
So now what I have to do (I think): 
  • Update orderer admin certs in the *system-channel* but with section of the block i have to modify? Channel, Application, Consortium or Orderer?
In the system channel config, scroll down to the first OrgMSP section and note the admin cert followed by the node OU section for the admin, client, 
orderer, and peer.  You will need to update these certs with your newly generated ones. Then scroll down to the Orderer MSP section and update those certs.  Then, scroll down to the ConsensusType section where you will see your consenter certs in the “consenters subsection.  Note that each consenter has a “client_tls_cert" and a “server_tls_cert".  In my case, these are the same on a per consenter basis.  You can double-check yours to be sure. 
  • Update cosenter certs with updated certs for orderer org, in this case i know that i have to do one update at a time but same as before: which section? 
Yes, see above.
  • Repeat previous steps for all "normal" channels
Yes, but start with the system channel, then the application channel.

I have a few tips for examining existing certs:

Base64 to PEM
export FLAG=$(if [ "$(uname -s)" == "Linux" ]; then echo "-w 0"; else echo "-b 0"; fi) 
echo <insert your base64 string here> | base64 --decode $FLAG 

PEM to Base64
export FLAG=$(if [ "$(uname -s)" == "Linux" ]; then echo "-w 0"; else echo "-b 0"; fi)
cat <insert path to .pem here> | base64 $FLAG 


I use certlogik.com to decode PEM certs and examine them.

Hope this helps,
Chris

On May 5, 2021, at 8:33 AM, Mattia Bolzonella <mattia.bolzonella@...> wrote:

Hi Chris,
Thank you for the quick reply. I will illustrate my situation, it's the worst possible scenario (production environment). So I'm on Fabric 2.2.2 with all my components except Fabric CAs which is 1.4.6 version.
I generated all my certs Orderer org and peer org with 2 separate CA but now i found out that *all* the certs are expired (except fo root CAs certs). So my situation is:
  • all admin certs (Orderer org and peer org) expired;
  • all MSP certs (singcerts I think it's how they are called) of both orgs of every components (I have 3 orderers and 2 peers) expired;
  • all TLS Certs expired;
I followed the Jira Issue which helped to start the orderers, even with the flag of ignoring TLS cert expiration date they were not starting. To resolve I had to generate new certs for the orderers MSP, i kept the expired TLS.
I generated new certs for the peer organization and started them pointing at the new certs. Plus to that peer cli has visibility on the expired MSP (and TLS) of orderer Org so in this way I managed to fetch the system-channel config block.

So now what I have to do (I think): 
  • Update orderer admin certs in the *system-channel* but with section of the block i have to modify? Channel, Application, Consortium or Orderer?
  • Update cosenter certs with updated certs for orderer org, in this case i know that i have to do one update at a time but same as before: which section?
  • Repeat previous steps for all "normal" channels
Is this the right procedure? 
I really appreciate your help, thank you!


Il giorno mer 5 mag 2021 alle ore 15:06 Chris Gabriel <alaskadd@...> ha scritto:
Hi Mattia,

Happy to help you.  Can you please provide a bit more detail about your environment?  For example, are you on Fabric 1.4 with a solo orderer, raft, etc.?
Beyond the above question, here are the relevant sections from the Fabric documentation to follow https://hyperledger-fabric.readthedocs.io/en/release-2.3/config_update.html#editing-a-config

To figure out what you have to edit, in the docs at the link above, pay close attention to the ‘Channel parameters that can be updated’ section as this contains a sample de-coded configuration with a section for each org msp and the orderer (click the dropdown where it says ‘click here to see the config’).  In the example, you will note that all certs are converted to base64 from pem so you will have to do this when you paste the new certs into the configuration.  Also, the example only shows a single raft node consenter, so it you have more you will have to update for each.

At a high level, the steps are to:
Set the environment variables for the org you are acting as
Pull and decode the configuration (to human readable form in the form of a json file. If you copy and paste the commands from the docs you will end up with a file called ‘modified_config.json’ which you will edit in a text editor or VSCode, etc.)
Modify (edit) the configuration
Re-encode the configuration reflecting your updated certs
Submit the update using the ‘peer channel update’ command
Get the necessary signatures according to your policies (note you will have to sign using your old certs before the update can happen)

I hope this helps,
Chris



On May 5, 2021, at 6:02 AM, Mattia Bolzonella <mattia.bolzonella@...> wrote:

Hi, i need to update the orderer org admin of the system channel, it's expired but i managed to start the orderer and peer following FAB-18384. Now i need to update the channel configuration but I have no clue on what to modify and how, can someone help me?



--

Mattia Bolzonella
Software Developer
Via G. Medici 9/a - 35138 Padova (PD)
+39 049 500 1 500  www.ifin.it
      


IFIN SISTEMI S.R.L. a socio unico
Via G. Medici 9/a
35138 Padova 

Le informazioni, i dati e le notizie contenute nella presente comunicazione e i relativi allegati sono di natura privata e come tali possono essere riservate e sono, comunque, destinate esclusivamente ai destinatari sopra indicati. La diffusione, la distribuzione e/o la copiatura del documento trasmesso da parte di qualsiasi soggetto diverso dal destinatario è proibita, sia ai sensi dell’art. 616 c.p., sia ai sensi del D.Lgs. 196/2003 e Regolamento UE 2016/679. Se avete ricevuto questo messaggio per errore, vi preghiamo di distruggerlo e di darcene immediata comunicazione anche inviando un messaggio di ritorno all'indirizzo e-mail del mittente. L’interessato può esercitare tutti i diritti previsti ai sensi degli articoli degli articoli 13, comma 2, lettere (b) e (d), 15-21 del Regolamento UE 2016/679, inviando un messaggio all'indirizzo e-mail del mittente o telefonando allo 049 500 1 500. Si prega di leggere Privacy Policy presente in https://ifin.it/privacy-policy-informativa-sui-cookies.


Re: Purge Private Data - by individual transaction - on trigger

Simeon MacMillen
 

Hi David,

In your original email, you mentioned a private data store in addition to the transient and private [world] state.  Is the "private data store" a separate, append-only ledger used with collections?

If there is any documentation on this, I would be interested to learn more.  (I tried searching through the documentation but haven't located any references to this term.  The Private Data page only mentions the state database and transient store.)


Regards,
Simeon MacMillen

Ref: https://hyperledger-fabric.readthedocs.io/en/release-2.3/private-data/private-data.html
Ref: https://hyperledger-fabric.readthedocs.io/en/release-2.3/private-data-arch.html

On 5/4/21 7:12 AM, David Enyeart wrote:

        Note that deletePrivateData only deletes from private state. The private data remains in the private data store (committed data) and transient store (uncommitted data) for other peers that may be running behind to pull.


Re: Update expired orderer org admin certificate and orderer certs #fabric-questions #fabric-orderer #signcerts #fabric

Mattia Bolzonella
 

Hi Chris,
Thank you for the quick reply. I will illustrate my situation, it's the worst possible scenario (production environment). So I'm on Fabric 2.2.2 with all my components except Fabric CAs which is 1.4.6 version.
I generated all my certs Orderer org and peer org with 2 separate CA but now i found out that *all* the certs are expired (except fo root CAs certs). So my situation is:
  • all admin certs (Orderer org and peer org) expired;
  • all MSP certs (singcerts I think it's how they are called) of both orgs of every components (I have 3 orderers and 2 peers) expired;
  • all TLS Certs expired;
I followed the Jira Issue which helped to start the orderers, even with the flag of ignoring TLS cert expiration date they were not starting. To resolve I had to generate new certs for the orderers MSP, i kept the expired TLS.
I generated new certs for the peer organization and started them pointing at the new certs. Plus to that peer cli has visibility on the expired MSP (and TLS) of orderer Org so in this way I managed to fetch the system-channel config block.

So now what I have to do (I think): 
  • Update orderer admin certs in the *system-channel* but with section of the block i have to modify? Channel, Application, Consortium or Orderer?
  • Update cosenter certs with updated certs for orderer org, in this case i know that i have to do one update at a time but same as before: which section?
  • Repeat previous steps for all "normal" channels
Is this the right procedure? 
I really appreciate your help, thank you!


Il giorno mer 5 mag 2021 alle ore 15:06 Chris Gabriel <alaskadd@...> ha scritto:
Hi Mattia,

Happy to help you.  Can you please provide a bit more detail about your environment?  For example, are you on Fabric 1.4 with a solo orderer, raft, etc.?
Beyond the above question, here are the relevant sections from the Fabric documentation to follow https://hyperledger-fabric.readthedocs.io/en/release-2.3/config_update.html#editing-a-config

To figure out what you have to edit, in the docs at the link above, pay close attention to the ‘Channel parameters that can be updated’ section as this contains a sample de-coded configuration with a section for each org msp and the orderer (click the dropdown where it says ‘click here to see the config’).  In the example, you will note that all certs are converted to base64 from pem so you will have to do this when you paste the new certs into the configuration.  Also, the example only shows a single raft node consenter, so it you have more you will have to update for each.

At a high level, the steps are to:
Set the environment variables for the org you are acting as
Pull and decode the configuration (to human readable form in the form of a json file. If you copy and paste the commands from the docs you will end up with a file called ‘modified_config.json’ which you will edit in a text editor or VSCode, etc.)
Modify (edit) the configuration
Re-encode the configuration reflecting your updated certs
Submit the update using the ‘peer channel update’ command
Get the necessary signatures according to your policies (note you will have to sign using your old certs before the update can happen)

I hope this helps,
Chris



On May 5, 2021, at 6:02 AM, Mattia Bolzonella <mattia.bolzonella@...> wrote:

Hi, i need to update the orderer org admin of the system channel, it's expired but i managed to start the orderer and peer following FAB-18384. Now i need to update the channel configuration but I have no clue on what to modify and how, can someone help me?



--

Mattia Bolzonella

Software Developer

mattia.bolzonella@...

Via G. Medici 9/a - 35138 Padova (PD)

+39 049 500 1 500  www.ifin.it
      



IFIN SISTEMI S.R.L. a socio unico

Via G. Medici 9/a
35138 Padova 


Le informazioni, i dati e le notizie contenute nella presente comunicazione e i relativi allegati sono di natura privata e come tali possono essere riservate e sono, comunque, destinate esclusivamente ai destinatari sopra indicati. La diffusione, la distribuzione e/o la copiatura del documento trasmesso da parte di qualsiasi soggetto diverso dal destinatario è proibita, sia ai sensi dell’art. 616 c.p., sia ai sensi del D.Lgs. 196/2003 e Regolamento UE 2016/679. Se avete ricevuto questo messaggio per errore, vi preghiamo di distruggerlo e di darcene immediata comunicazione anche inviando un messaggio di ritorno all'indirizzo e-mail del mittente. L’interessato può esercitare tutti i diritti previsti ai sensi degli articoli degli articoli 13, comma 2, lettere (b) e (d), 15-21 del Regolamento UE 2016/679, inviando un messaggio all'indirizzo e-mail del mittente o telefonando allo 049 500 1 500. Si prega di leggere Privacy Policy presente in https://ifin.it/privacy-policy-informativa-sui-cookies.


Re: Update expired orderer org admin certificate and orderer certs #fabric-questions #fabric-orderer #signcerts #fabric

Chris Gabriel
 

Hi Mattia,

Happy to help you.  Can you please provide a bit more detail about your environment?  For example, are you on Fabric 1.4 with a solo orderer, raft, etc.?
Beyond the above question, here are the relevant sections from the Fabric documentation to follow https://hyperledger-fabric.readthedocs.io/en/release-2.3/config_update.html#editing-a-config

To figure out what you have to edit, in the docs at the link above, pay close attention to the ‘Channel parameters that can be updated’ section as this contains a sample de-coded configuration with a section for each org msp and the orderer (click the dropdown where it says ‘click here to see the config’).  In the example, you will note that all certs are converted to base64 from pem so you will have to do this when you paste the new certs into the configuration.  Also, the example only shows a single raft node consenter, so it you have more you will have to update for each.

At a high level, the steps are to:
Set the environment variables for the org you are acting as
Pull and decode the configuration (to human readable form in the form of a json file. If you copy and paste the commands from the docs you will end up with a file called ‘modified_config.json’ which you will edit in a text editor or VSCode, etc.)
Modify (edit) the configuration
Re-encode the configuration reflecting your updated certs
Submit the update using the ‘peer channel update’ command
Get the necessary signatures according to your policies (note you will have to sign using your old certs before the update can happen)

I hope this helps,
Chris



On May 5, 2021, at 6:02 AM, Mattia Bolzonella <mattia.bolzonella@...> wrote:

Hi, i need to update the orderer org admin of the system channel, it's expired but i managed to start the orderer and peer following FAB-18384. Now i need to update the channel configuration but I have no clue on what to modify and how, can someone help me?


Update expired orderer org admin certificate and orderer certs #fabric-questions #fabric-orderer #signcerts #fabric

Mattia Bolzonella
 

Hi, i need to update the orderer org admin of the system channel, it's expired but i managed to start the orderer and peer following FAB-18384. Now i need to update the channel configuration but I have no clue on what to modify and how, can someone help me?


How to run the example endorsement plugin on the fabric 2.2? #fabric-endorser #hyperledger-fabric

1139073321xdvg@...
 

Hi fabirc experts, I met some problems when I write my endosement plugins.My steps are followed.
1   I modify the docker-compose-test-net.yaml in the test-network/docker, add " - ../plugin_test:/etc/hyperledger/fabric/plugin" in the two peers's volume;
2   I run "go build -buildmode=plugin -o DefaultEndorsement.so plugin.go" in the core/handlers/plugin, to make the DefaultEndorsement.so file.
3   I move the DefaultEndorsement.so to the plugin_test directory which is created in the step 1.
4   I modify the core.yaml in the fabric-samples/config, with such content:
endorsers:
         escc:
           name: DefaultEndorsement
          library:
          DefaultEndorsement:
            name: DefaultEndorsement
 
            library: /etc/hyperledger/fabric/plugin/DefaultEndorsement.so
5. then I run the test-network ,follow the official guide. is./network.sh up createChannel and this guide "Deploying a smart contract to a channel" in the official guide; in "approveformyorg"  " checkcommitreadiness" "commit" I add the "-E DefaultmetEndorsement" in the tail;
6. then I run the statement
peer chaincode invoke -o localhost:7050 --ordererTLSHostnameOverride orderer.example.com --tls true --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n fabcar --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses localhost:9051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"function":"initLedger","Args":[]}'

return a false: 
Error: endorsement failure during invoke. response: status:500 message:"endorsing with plugin failed: plugin with name DefaultEndorsement could not be used: plugin with name DefaultEndorsement wasn't found"

but I run into the peer docker , I can see the DefaultEndorsement.so in the docker, I do not know I make mistake in which step, can experts tell me how to fix this mistake, I am a new hand of fabric, and do not know what to do next, thanks very much!


Re: [External] : [Hyperledger Fabric] IoT with frequent data and possibly incorrect data sometimes

Nikos Karamolegkos
 

So mark in order to recap, you propose each ED to be a different user which send data via REST to an aggregator (i.e a BC client) who acts as intermediate to match the data from each ED to the respective BC user? Are this EDs belong to the same organization in order use the same aggregator?


回复: missing tags for go chaincode developement dependencies

david liu <david-khala@...>
 

Hi Fabric maintainers,

Is there any updates on this? I am happy to hear any consideration on why not pushing named git tag to fabric-chaincode-go and fabric-protos-go.

If it is intended and designed as a WON’T DO, an clarification is welcomed to help us feedback to community members.

 

发件人: 刘 宇翔
发送时间: 2021420 21:05
收件人: fabric@...; twg-china@...
主题: missing tags for go chaincode developement dependencies

 

Hi Fabric maintainers, 


As some community member and me found for a while, 

Both following repositories have no git tags yet pushed to Github

github.com/hyperledger/fabric-chaincode-go
github.com/hyperledger/fabric-protos-go

This will introduce a result that fabric go chaincode developer have to suffer from go.mod dependency versioning issue. such as 

v0.0.0-20200511190512-bcfeb58dd83a
 
Each time we get lost in what 20200511190512 indicates. We have to guess whether it is 2.2.x or 2.3.x
 
Can you consider give tags to them, in a similar way in fabric itself. then we could pin to use v2.2.x as dependency version.


Best Regards,

David Liu


Private Chaincode Lab - Tue, 05/04/2021 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Private Chaincode Lab

When:
Tuesday, 4 May 2021
8:00am to 9:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Organizer:
bur@...

Description:
Two of the Hyperleger Labs projects (private data objects and private chain code) are collaborating to develop a "private smart contracts" capability.

Join Zoom Meeting https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09 Meeting ID: 518 494 7650 Passcode: 475869


Re: Purge Private Data - by individual transaction - on trigger

David Enyeart
 

FAB-18461 would help if a single organization should no longer be authorized to a certain piece of private data. They could call an API on their own peers to purge the private data, while the other organizations could retain it.

The shared ledger only has a hash of the private data. Each individual peer maintains their own private data stores and ensures the private data matches the on-chain hashes. So deletion from a single org's peer(s) would not be a divergence issue with respect to the shared ledger.

I've updated the Jira item with the same info.


Thanks,

Dave Enyeart

Simeon MacMillen ---05/04/2021 07:49:53 AM---Hi David, Thank you for this information, including the two JIRAs.

From: Simeon MacMillen <industrial_eng@...>
To: David Enyeart <enyeart@...>
Cc: fabric <fabric@...>
Date: 05/04/2021 07:49 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Purge Private Data - by individual transaction - on trigger





Hi David, Thank you for this information, including the two JIRAs. FAB-5097 would definitely help satisfy the ISO requirement that I referenced. I'm not sure that I understand the other JIRA (FAB-18461).  If data is only deleted on an individual ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd

Hi David,

Thank you for this information, including the two JIRAs.

FAB-5097 would definitely help satisfy the ISO requirement that I referenced.

I'm not sure that I understand the other JIRA (FAB-18461).  If data is only deleted on an individual peer, would it continue to live on other collection member ledgers?  Would the deleted transaction get re-copied over to the original peer or would the collection members need to maintain divergent copies of the collection ledger?

I agree with you on channel-wide purge being more important (from my perspective on compliance).

Regards,
Simeon MacMillen

On 5/4/21 7:12 AM, David Enyeart wrote:

      Note that deletePrivateData only deletes from private state. The private data remains in the private data store (committed data) and transient store (uncommitted data) for other peers that may be running behind to pull. There are a couple stories being considered to deal with this other data in future versions of Fabric:

      https://jira.hyperledger.org/browse/FAB-5097
      GDPR for private data - On demand delete of private data prior to block-to-live policy based on a delete transaction. Option for transaction resulting from DelPrivateData() chaincode API to purge key from peer's private data store and transient store on all peers, in addition to deleting from private state database on all peers.

      https://jira.hyperledger.org/browse/FAB-18461
      FAB-18461 GDPR for private data - On demand delete of private data prior to block-to-live policy on an individual peer. API to purge a private data key from private state, private data store, and transient store on an individual peer (could be done before or after or instead of DelPrivateData() chaincode API).

      Basically, channel-wide versus peer-scoped purge, while keeping the hash on the chain. I assume the former would be more important, but would like to hear thoughts from people familiar with the ISO and GDPR requirements.

      Also, let us know if anybody could assist to expedite an implementation, as many people have asked for such a feature.


      Dave Enyeart

      "Nicholas Leonardi via lists.hyperledger.org" ---05/03/2021 07:21:54 PM--- Hey Simeon, - You can purge using the deletePrivateData function.https://urldefense.proofpoint.com/

      From:
      "Nicholas Leonardi via lists.hyperledger.org" <nlzanutim=yahoo.com@...>
      To:
      fabric <fabric@...>, Simeon MacMillen <industrial_eng@...>
      Date:
      05/03/2021 07:21 PM
      Subject:
      [EXTERNAL] Re: [Hyperledger Fabric] Purge Private Data - by individual transaction - on trigger
      Sent by:
      fabric@...





      Hey Simeon, - You can purge using the deletePrivateData function.
      https://hyperledger.github.io/fabric-chaincode-node/release-1.4/api/fabric-shim.ChaincodeStub.html#deletePrivateData__anchor - You can't purge a transaction on a block, you purge ZjQcmQRYFpfptBannerStart
      This Message Is From an External Sender

      This message came from outside your organization.

      ZjQcmQRYFpfptBannerEnd

      Hey Simeon,


      - You can purge using the deletePrivateData function.

      https://hyperledger.github.io/fabric-chaincode-node/release-1.4/api/fabric-shim.ChaincodeStub.html#deletePrivateData__anchor

      - You can't purge a transaction on a block, you purge the data that you inserted into the database using the
      function above


      Regards,
      Nick


      Em segunda-feira, 3 de maio de 2021 16:41:45 BRT, Simeon MacMillen
      <industrial_eng@...> escreveu:


      According to the documentation, Private Data can be purged after a
      pre-determined number of blocks, based on a Collection 'blockToLive' value.


      - Is there any other way of purging private data when the purge
      date/block quantity is not known in advance (e.g. schedule a purge after
      block creation)?


      - Is there any way to purge only a single transaction in a channel?


      I am looking for how to "dispose" of data as needed based on customer or
      industry regulations (e.g. ISO 9001:2015 7.5.3.2 d)).



      Regards,
      Simeon MacMillen


      Referenced link:

      https://hyperledger-fabric.readthedocs.io/en/release-2.3/private_data_tutorial.html#pd-purge












Re: Purge Private Data - by individual transaction - on trigger

Simeon MacMillen
 

Hi David,

Thank you for this information, including the two JIRAs.

FAB-5097 would definitely help satisfy the ISO requirement that I referenced.

I'm not sure that I understand the other JIRA (FAB-18461).  If data is only deleted on an individual peer, would it continue to live on other collection member ledgers?  Would the deleted transaction get re-copied over to the original peer or would the collection members need to maintain divergent copies of the collection ledger?

I agree with you on channel-wide purge being more important (from my perspective on compliance).

Regards,
Simeon MacMillen

On 5/4/21 7:12 AM, David Enyeart wrote:

Note that deletePrivateData only deletes from private state. The private data remains in the private data store (committed data) and transient store (uncommitted data) for other peers that may be running behind to pull. There are a couple stories being considered to deal with this other data in future versions of Fabric:

https://jira.hyperledger.org/browse/FAB-5097
GDPR for private data - On demand delete of private data prior to block-to-live policy based on a delete transaction. Option for transaction resulting from DelPrivateData() chaincode API to purge key from peer's private data store and transient store on all peers, in addition to deleting from private state database on all peers.

https://jira.hyperledger.org/browse/FAB-18461
FAB-18461 GDPR for private data - On demand delete of private data prior to block-to-live policy on an individual peer. API to purge a private data key from private state, private data store, and transient store on an individual peer (could be done before or after or instead of DelPrivateData() chaincode API).

Basically, channel-wide versus peer-scoped purge, while keeping the hash on the chain. I assume the former would be more important, but would like to hear thoughts from people familiar with the ISO and GDPR requirements.

Also, let us know if anybody could assist to expedite an implementation, as many people have asked for such a feature.


Dave Enyeart

"Nicholas Leonardi via lists.hyperledger.org" ---05/03/2021 07:21:54 PM--- Hey Simeon, - You can purge using the deletePrivateData function.https://urldefense.proofpoint.com/

From: "Nicholas Leonardi via lists.hyperledger.org" <nlzanutim=yahoo.com@...>
To: fabric <fabric@...>, Simeon MacMillen <industrial_eng@...>
Date: 05/03/2021 07:21 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Purge Private Data - by individual transaction - on trigger
Sent by: fabric@...





Hey Simeon, - You can purge using the deletePrivateData function. https://hyperledger.github.io/fabric-chaincode-node/release-1.4/api/fabric-shim.ChaincodeStub.html#deletePrivateData__anchor - You can't purge a transaction on a block, you purge ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hey Simeon,

- You can purge using the deletePrivateData function.
https://hyperledger.github.io/fabric-chaincode-node/release-1.4/api/fabric-shim.ChaincodeStub.html#deletePrivateData__anchor

- You can't purge a transaction on a block, you purge the data that you inserted into the database using the
function above

Regards,
Nick

Em segunda-feira, 3 de maio de 2021 16:41:45 BRT, Simeon MacMillen <industrial_eng@...> escreveu:


According to the documentation, Private Data can be purged after a
pre-determined number of blocks, based on a Collection 'blockToLive' value.

- Is there any other way of purging private data when the purge
date/block quantity is not known in advance (e.g. schedule a purge after
block creation)?

- Is there any way to purge only a single transaction in a channel?

I am looking for how to "dispose" of data as needed based on customer or
industry regulations (e.g. ISO 9001:2015 7.5.3.2 d)).


Regards,
Simeon MacMillen

Referenced link:
https://hyperledger-fabric.readthedocs.io/en/release-2.3/private_data_tutorial.html#pd-purge













Re: Purge Private Data - by individual transaction - on trigger

David Enyeart
 

Note that deletePrivateData only deletes from private state. The private data remains in the private data store (committed data) and transient store (uncommitted data) for other peers that may be running behind to pull. There are a couple stories being considered to deal with this other data in future versions of Fabric:

https://jira.hyperledger.org/browse/FAB-5097
GDPR for private data - On demand delete of private data prior to block-to-live policy based on a delete transaction. Option for transaction resulting from DelPrivateData() chaincode API to purge key from peer's private data store and transient store on all peers, in addition to deleting from private state database on all peers.

https://jira.hyperledger.org/browse/FAB-18461
FAB-18461 GDPR for private data - On demand delete of private data prior to block-to-live policy on an individual peer. API to purge a private data key from private state, private data store, and transient store on an individual peer (could be done before or after or instead of DelPrivateData() chaincode API).

Basically, channel-wide versus peer-scoped purge, while keeping the hash on the chain. I assume the former would be more important, but would like to hear thoughts from people familiar with the ISO and GDPR requirements.

Also, let us know if anybody could assist to expedite an implementation, as many people have asked for such a feature.


Dave Enyeart

"Nicholas Leonardi via lists.hyperledger.org" ---05/03/2021 07:21:54 PM--- Hey Simeon, - You can purge using the deletePrivateData function.https://urldefense.proofpoint.com/

From: "Nicholas Leonardi via lists.hyperledger.org" <nlzanutim=yahoo.com@...>
To: fabric <fabric@...>, Simeon MacMillen <industrial_eng@...>
Date: 05/03/2021 07:21 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Purge Private Data - by individual transaction - on trigger
Sent by: fabric@...





Hey Simeon, - You can purge using the deletePrivateData function. https://hyperledger.github.io/fabric-chaincode-node/release-1.4/api/fabric-shim.ChaincodeStub.html#deletePrivateData__anchor - You can't purge a transaction on a block, you purge ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hey Simeon,

- You can purge using the deletePrivateData function.
https://hyperledger.github.io/fabric-chaincode-node/release-1.4/api/fabric-shim.ChaincodeStub.html#deletePrivateData__anchor

- You can't purge a transaction on a block, you purge the data that you inserted into the database using the
function above

Regards,
Nick

Em segunda-feira, 3 de maio de 2021 16:41:45 BRT, Simeon MacMillen <industrial_eng@...> escreveu:


According to the documentation, Private Data can be purged after a
pre-determined number of blocks, based on a Collection 'blockToLive' value.

- Is there any other way of purging private data when the purge
date/block quantity is not known in advance (e.g. schedule a purge after
block creation)?

- Is there any way to purge only a single transaction in a channel?

I am looking for how to "dispose" of data as needed based on customer or
industry regulations (e.g. ISO 9001:2015 7.5.3.2 d)).


Regards,
Simeon MacMillen

Referenced link:
https://hyperledger-fabric.readthedocs.io/en/release-2.3/private_data_tutorial.html#pd-purge













Re: Purge Private Data - by individual transaction - on trigger

Nicholas Leonardi
 

Hey Simeon,

- You can purge using the deletePrivateData function.

- You can't purge a transaction on a block, you purge the data that you inserted into the database using the 
function above

Regards,
Nick

Em segunda-feira, 3 de maio de 2021 16:41:45 BRT, Simeon MacMillen <industrial_eng@...> escreveu:


According to the documentation, Private Data can be purged after a
pre-determined number of blocks, based on a Collection 'blockToLive' value.

- Is there any other way of purging private data when the purge
date/block quantity is not known in advance (e.g. schedule a purge after
block creation)?

- Is there any way to purge only a single transaction in a channel?

I am looking for how to "dispose" of data as needed based on customer or
industry regulations (e.g. ISO 9001:2015 7.5.3.2 d)).


Regards,
Simeon MacMillen

Referenced link:










Purge Private Data - by individual transaction - on trigger

Simeon MacMillen
 

According to the documentation, Private Data can be purged after a pre-determined number of blocks, based on a Collection 'blockToLive' value.

- Is there any other way of purging private data when the purge date/block quantity is not known in advance (e.g. schedule a purge after block creation)?

- Is there any way to purge only a single transaction in a channel?

I am looking for how to "dispose" of data as needed based on customer or industry regulations (e.g. ISO 9001:2015 7.5.3.2 d)).


Regards,
Simeon MacMillen

Referenced link: https://hyperledger-fabric.readthedocs.io/en/release-2.3/private_data_tutorial.html#pd-purge


Re: UNABLE_TO_GET_ISSUER_CERT_LOCALLY Error on chaincode install #fabric-sdk-node #tls #fabric

Kevin X
 

Yes, docker is installed and local network is up.

This is happening at npm install stage likely when chaincode docker image is built.

841 - 860 of 10742