It's UWAweek 20 (1st semester, week 11)

help3007

This forum is provided to promote discussion amongst students enrolled in CITS3007 Secure Coding. If posting a question, it's suggested you check first whether your question is answered in the unit Frequently Asked Questions (FAQ) list, and use the search box (on the right) to see if an answer to your question has already been posted.

Please consider offering answers and suggestions to help other students! And if you fix a problem by following a suggestion here, it would be great if other interested students could see a short "Great, fixed it!"  followup message.

Note that any posts must comply with the UWA Code of Conduct and the UWA Academic Conduct Policy. That means you should (a) treat everyone with respect and courtesy, and (b) not post your solutions to an assessment that's in progress.

If asking a programming question, it's recommended you read How do I ask a good question? If reporting or troubleshooting a bug in software used in the unit, it's recommend you read How to report bugs effectively.
Displaying selected article
Showing 1 of 77 articles.
Currently 1 other person reading this forum.


 UWA week 19 (1st semester, week 10) ↓
SVG not supported

Login to reply

👍?
helpful
1:13pm Mon 6th May, Arran S.

Hi,

Sure, that sounds mostly right. The code really should be pretty easy, so there should be plenty of time to focus on making sure your code is correct, covers edge cases, and is clear and understandable. Therefore markers will expect a fairly high standard when it comes to those things, and to following secure coding best practices.

I will say, though, that whether the implementations should be "robust" is a bit more questionable. Normally when we say "robust", we mean that a program should handle errors gracefully. However, that usually applies only to whole programs, or to user-facing code (as opposed to developer-facing), or code that takes input that could potentially be malformed or from an untrusted source. In this project, there's only one function that falls into that category, namely cli.

All the functions other than cli have clear preconditions and postconditions, and the onus is on the developer calling them to ensure that the preconditions hold. If the preconditions don't hold, the result of the function will simply be undefined (and probably unexpected) – the only thing you can do if you do discover a precondition doesn't hold is use an assert() call to abort operation.

For instance, consider something like the memcpy function in the C library (see here). It's a requirement imposed on the caller that both arguments must point to valid locations in memory, and that they must not overlap, and that reading or writing n bytes from them won't take you out of bounds. Is there anything you could or should do to make an implementation of memcpy "robust"? I'd suggest there isn't, and in any case you shouldn't. However, I'll discuss this more in this week's lecture – stay tuned :)

Cheers

Arran

ANONYMOUS wrote:

> Hi all, Just checking if I understand the project right,
> so we need to implement encryption and decryption functions for both the Caesar and Vigenere ciphers, following the provided specifications in the crypto.h header file. Additionally, we'll create a command-line interface (CLI) function to facilitate easy testing of your code. Ensuring code quality by adhering to secure coding practices and proper documentation. Testing thoroughly and handling edge cases are essential for robust implementation.
> Is that's sound right?

The University of Western Australia

Computer Science and Software Engineering

CRICOS Code: 00126G
Written by [email protected]
Powered by history
Feedback always welcome - it makes our software better!
Last modified  5:07AM Sep 06 2023
Privacy policy