It’s common for people to be confused by data abstraction and encapsulation and treat the concept of abstraction as encapsulation or information hiding. That’s not the case. The following definitions come from ISO/IEC/IEEE 24765:2017 Systems and software engineering — Vocabulary.

Data Abstraction

1. process of extracting the essential characteristics of data by defining data types and their associated functional characteristics and disregarding representation details
2. result of the process in (1)

Encapsulation

1. software development technique that consists of isolating a system function or a set of data and operations on those data within a module and providing precise specifications for the module
2. concept that access to the names, meanings, and values of the responsibilities of a class is entirely separated from access to their realization [IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject), 3.1.54]
3. the idea that a module has an outside that is distinct from its inside, that it has an external interface and an internal implementation

Information Hiding

1. software development technique in which each module’s interfaces reveal as little as possible about the module’s inner workings and other modules are prevented from using information about the module that is not in the module’s interface specification
2. containment of a design or implementation decision in a single module so that the decision is hidden from other modules

BlueKrypt provides a fantastic summary of recommendations for Key Management from various authorities. The user interface is terrific as well! Great job!

• Lenstra and Verheul Equations (2000)
• Lenstra Updated Equations (2004)
• ECRYPT-CSA Recommendations (2018)
• NIST Recommendations (2020)
• ANSSI Recommendations (2014)
• NSA CNSA Suite (2016)
• Network Working Group RFC3766 (2004)
• BSI Recommendations (2020)

ClickOnce and Strongly-named Assembly

I build a multi-target .NET project, DomainModel, that supports .NET framework and .NET Core and publish the Windows Form Application as the client using Microsoft ClickOnce requiring the shared DomainModel be strongly-named. However, it doesn’t make sense on a docker node in Azure.

Publish Error on Azure Docker Node

Docker command failed with exit code 1.
#15 ERROR: executor failed running [/bin/sh -c dotnet build "Services.csproj" -c Release -o /app/build]: exit code: 1
#15 64.73 /usr/share/dotnet/sdk/5.0.302/Microsoft.Common.CurrentVersion.targets(3325,5): error : PFX signing not supported on .NET Core [/src/DomainModel/DomainModel.csproj]
#15 64.76 Build FAILED.

Conclusion

I have to manually check the “Sign the assembly” option when publishing the Windows Form application and uncheck it when publishing services to Azure docker nodes.

WUSON Practice Field for Wentz Wu (a CISSP test bank) relies on the identity provider, Auth0, for authentication. When a user logs into the system for the first time, the system will create an account on Auth0 automatically. However, a user needs some roles to get access to the test bank.